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EXECUTIVE  SUMMARY 

This  Small  Business  Innovative  Research  (SBIR)  effort  defines,  identifies  and  evaluates  concepts, 
architectures,  technologies  and  designs  for  inter-satellite  links  (ISLs)  used  to  link  collaborating 
clusters,  or  swarms,  of  small  satellites  flying  in  close  formation  working  cooperatively  via  a  satellite 
local  area  network.  The  TechSat  21  (TS21)  satellite  program  from  the  Air  Force  Research 
Laboratory  Space  Vehicles  Directorate  served  as  the  target  ISL  application.  The  TS  21  satellite 
mission  uses  up  to  eight  satellites  operating  as  distributed,  space  based  radars  linked  to  form  one  large, 
high  resolution  virtual  satellite  sparse  aperture  radar  (SAR)  for  earth  surface  and  earth  atmosphere 
observation  missions.  A  distributed,  satellite  SAR  LAN  serves  as  a  most  technologically  challenging 
ISL  application. 

The  main  performance  requirements  to  be  met  were:  100  Mbps  data  transfer  rates  between 
satellites,  3  mm  satellite  relative  position  determination  and  20  ps  satellite  cluster  timing 
synchronization.  Other  design  constrain  requirements  included  a  20  W,  5  kg,  0.3  m  and  $300K  (in 
quantities  of  300)  power,  weight,  volume  and  cost  budget.  An  important  SBIR  contractual  and 
technically  significant  requirement  included  defining  an  ISL  with  commercialization  potential  for  non 
military  wireless  communication  markets. 

An  operations  concept  was  written  to  define  the  needed  functionality  based  on  actual 
applications  of  ISLs,  to  provide  a  requirements  basis,  to  allow  evaluation  of  wireless  existing  and 
emerging  technologies,  and  to  provide  a  basis  for  defining  architectures,  hardware  and  software  for  an 
operational  satellite  ISL.  The  operations  concept  provided  all  parties,  operators,  designers, 
implementors,  testers  and  integrators  with  an  understandable  view  of  the  ISL  functions. 

An  ISL  requirements  document  was  written  that  utilized  a  template  to  define  requirements  by 
categories  and  attributes,  organized  in  such  a  manner  as  to  facilitate  different  parties  views  of  and 
needs  for  ISL  requirements.  The  requirements  document  provided  the  necessary  single  source  of 
specifications  for  evaluating  wireless  technologies,  defining  recommended  ISL  implementations, 
performing  cost  and  risk  tradeoffs  and  gaining  user  community  acceptance  of  ISL  implementations. 
The  requirements  document  also  defined  the  ISL  system  boundaries. 

The  physical  and  data  link  layer  (including  media  access  control)  information  transmission 
and  reception  hardware  architecture  candidates  for  satellite  LANs  and  ISLs  were  identified.  Existing 
and  in  development  satellite  system,  cellular,  personal  communications  services,  and  other  wireless 
LAN  and  transmission/reception  hardware  provided  the  base  from  which  hardware  candidates  were 
selected. 

Upper  layer  (including  network,  transport  and  application)  transmission  and  reception 
hardware  and  software  (e.g.,  protocol)  candidates  for  satellite  LANs  and  ISLs  were  identified  and 
analyzed.  A  high-level  data  link  control  (HDLC)  protocol  extension  mechanism  was  defined  for 
additional  functionality  (e.g.,  encryption,  compression)  and  better  performance  (e.g.,  selective  repeat 
automatic  repeat  request  with  multiple  buffers)  while  maintaining  standard  HDLC  interoperability. 

Previous  task  outputs  were  combined  and  a  candidate  ISL  architecture,  hardware  and  software 
were  defined.  ISL  requirements  were  used  to  evaluate  candidates  and  define  the  recommended  ISL 
architecture  and  implementation  approach. 

An  ISL  Engineering  Development  Unit  (EDU)  was  defined  from  Code  Division  Multiple 
Access  (CDMA)  receiver,  transmitter,  processing,  antenna  and  interface  components.  Usage  of 
commercial-off-the-shelf  components  was  identified  and  maximized  for  the  development  of  an  ISL 
EDU  by  30  Sep  2000. 

A  radio  frequency  (RF)  based  CDMA  ISL  system  was  defined  that  achieves  three  technology 
firsts:  100  Mbps  wireless  CDMA  transmission,  3  mm  position  accuracy  determination  and  20  ps 
sender-transmitter  timing  synchronization,  all  via  only  the  RF  CDMA  signal.  A  commercially 
marketable  100  Mbps  wireless  CDMA  transmission  device  is  also  easily  realized  from  the  resulting 
design. 
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1.0  INTRODUCTION 

Trends  towards  less  costly  approaches  to  meet  space  satellite  mission  requirements  have  generated 
new  architectures  for  space  systems.  One  such  concept  is  the  idea  of  collaborating  clusters,  or 
swarms,  of  small  satellites  flying  in  close  formation  working  cooperatively  to  do  the  job  of  a  larger, 
more  complex  satellite,  forming  a  virtual  satellite  via  a  space  based  local  area  network  (LAN). 

Virtual  satellites  and  virtual  satellite  missions  were  proposed  by  the  principal  investigator  for  the 
National  Aeronautics  and  Space  Administration  (NASA)  satellites  and  robots  nearly  a  decade  ago 
[S91],  The  virtual  mission  concept  is  the  carrying  out  of  tasks  or  missions  through  coordinated  use 
of  a  number  of  independent,  simple,  one  function  satellites  or  robots,  instead  of  using  one,  complex, 
multi-function  satellite  or  robot.  The  mission  is  a  virtual  mission  in  that  a  number  of  small  satellites 
carry  out  their  individual  missions  in  a  coordinated  manner,  acting  as  one  to  perform  one  higher 
level,  or  virtual  mission.  The  small  satellites  maintain  relative  autonomy  (attitude  and  control 
correction)  and  share  processing  capabilities.  This  concept  of  virtual  satellite  clusters  has  four 
significant  advantages  for  space  missions:  greatly  reduces  the  cost,  reduces  the  risks,  provides  for  the 
insertion  and  utilization  of  recent  technology  advancements,  and  last  but  not  least,  allows  for  the 
achievement  of  missions  not  possible  with  single  satellites.  Small  satellites  can  be  launched  from 
inexpensive  platforms  such  as  airplanes,  cruise  missiles  and  small  rockets.  A  multitude  of  small 
satellites  can  be  launched  from  one,  large  lift  vehicle  such  as  the  Titan  and  Delta  rockets,  and  the 
Space  Shuttle,  spreading  the  launch  and  integration  costs  over  a  number  of  satellites.  Risk  is  reduced 
in  that  the  failure  of  a  single  satellite  does  not  necessarily  cause  the  loss  of  a  mission.  Since  a  number 
of  virtual  satellites  can  be  constructed  from  a  given  set  of  small  satellites,  the  loss  of  one  particular 
function  still  enables  the  achievement  of  many  other  missions.  Risk  is  also  reduced  through  the 
ability  to  utilize  small,  inexpensive  launch  vehicles  to  launch  a  replacement  satellite  in  much  less 
time  than  with  a  heavy  lift  launch  vehicle.  Since  small  satellites  are  much  easier  to  build,  require 
much  less  launch  vehicle  integration  effort  and  time,  and  can  be  launched  from  a  number  of  mobile, 
existing  small  and  inexpensive  launch  platforms,  newer  technology  can  be  incorporated  in  much  less 
time.  Since  the  time  to  design,  build  and  launch  a  small  satellite  can  be  reduced  by  years  over  that  of 
a  large,  complex  satellite,  the  technology  in  the  small  satellite  does  not  lag  its  terrestrial  counterparts 
by  the  almost  10  years  found  in  current  satellites.  Newer  sensor  and  payload  technology,  as  well  as 
forming  a  virtual  satellite  through  cooperating  satellite  clusters,  allows  for  conducting  missions  not 
possible  with  a  single,  complex,  older  technology  satellite.  A  single  satellite  is  limited  in  size,  weight 
and  power  consumption,  while  a  satellite  cluster  is  unlimited  in  these  areas  as  well  as  unlimited  in  the 
number  of  payloads.  More  satellites  with  newer  technology  can  be  linked  to  form  virtual  satellites 
that  can  conduct  virtual  missions  not  even  conceived  of  at  the  time  the  satellites  were  designed  or 
launched. 

The  virtual  satellite  and  the  corresponding  satellite  LAN  can  be  constructed  by  having  the 
payloads  or  sensors  of  collaborating  clusters,  or  swarms,  of  small  satellites  connected  through  inter¬ 
satellite  communication  links  (ISLs)  in  order  to  coordinate  the  achievement  of  mission  objectives 
and  tasks.  The  ISLs  form  the  wireless  connections  of  the  satellite  LAN. 

The  Air  Force  Research  Laboratory  Space  Vehicles  Directorate  (AFRL/VS)  funded  this  Small 
Business  Innovative  Research  (SBIR)  effort  for  the  development  of  an  ISL  subsystem  for  the 
AFRL/VS  TechSat  21  (TS21)  satellite  program.  The  TS  21  satellite  mission  uses  up  to  eight 
satellites  operating  as  distributed,  space  based  radars  linked  to  form  one  large,  high  resolution  virtual 
satellite  sparse  aperture  radar  (SAR)  for  earth  surface  and  earth  atmosphere  observation  missions. 

The  top  level  objective  for  the  effort  became  the  definition  of  a  TS21  ISL  capable  of 
omnidirectional,  simultaneous,  high  data  rate,  secure  communication  required  to  connect  up  to 
sixteen  satellites  at  close  range  (<  1  km)  and  satellite  clusters  at  long  range  (>  1  km).  A  number  of 
initial  requirements  were  also  placed  on  the  ISL  definition  including  a  S:  100  Mbps  data  rate,  bit  error 
rates,  <  10'6,  weight  <  0.5  kg,  power  consumption  <  1  W,  and  space  survivable  for  10  years  in  low 
Earth  orbit  (LEO).  An  additional  SBIR  contractual  requirement  was  that  the  resulting  ISL  be 
commercially  marketable.  Near  the  end  of  the  effort,  the  100  Mbps  data  transmission  requirement 
was  replaced  by  two  new  requirements:  20  ps  satellite  cluster  timing  synchronization  and  3  mm 
satellite  relative  position  determination. 
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MiTech  Incorporated  divided  the  effort  into  a  number  of  tasks  in  order  to  achieve  the  objectives: 

1 .  Define  Operations  Concept  for  Short  and  Long  Range  Satellite  Cluster  LANs 

2.  Define  Satellite  LAN  Requirements 

3 .  Identify  and  Define  ISL  Architecture 

4.  Identify  and  Analyze  Wireless  Software/Hardware  Communication  Protocols 

5.  Define  ISL  Engineering  Development  Unit  (EDU). 

Each  task  provides  a  part  of  the  required  system  engineering  methodology  to  achieve  the  objective 
of  defining  concepts,  technologies  and  architectures  for  an  ISL  satellite  subsystem  with  the  desired 
capabilities  and  characteristics.  Each  task  is  now  discussed  in  turn. 
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2.0  SATELLITE  LAN  ISL  OPERATIONS  CONCEPT 

The  operations  concept  is  a  description  of  how  the  mission  statement  and  mission  objectives  for  a 
system  of  interest  are  accomplished.  The  system  of  interest  is  a  set  of  ISLs  used  in  a  satellite  LAN 
or  satellite  LAN-like  applications.  This  operations  concept  documents  how  ISLs,  used  to  link  a 
number  of  satellites  into  a  single  virtual  satellite,  interact  with  the  various  entities  involved  to 
achieve  the  satellite  mission  objectives.  This  operations  concept  provides  a  means  to  communicate 
the  purpose,  activities,  inputs,  outputs  and  physical  constraints  of  ISLs  in  the  context  of  planned  and 
foreseeable  satellite  missions.  The  operations  concept  provides  a  common  framework  for 
organizations,  individuals  and  systems  involved  with  ISL  system  application,  specification, 
development  and  use. 

2.1  Purpose 

The  purpose  of  this  operations  concept  is  to  serve  as  the  requirements  source  for  a)  defining  the 
needed  functionality  to  implement  ISLs  for  satellite  LAN  missions,  b)  evaluating  existing  and 
emerging  wireless  technologies,  and  c)  defining  architectures,  hardware  and  software  for 
recommended  ISL  implementations  capable  of  conducting  planned  and  foreseeable  space  missions. 
The  operations  concept  also  serves  to  define  the  ISL  system  boundaries.  This  ISL  operations 
concept  provides  for  a  wide  range  of  ISL  applications.  A  wide  range  and  number  of  satellite  missions 
with  satellite  LAN-like  interconnections  should  therefore  be  able  to  make  use  of  this  ISL  operations 
concept  for  the  above  stated  purposes. 

2.2  Scope 

The  scope  of  this  operations  concept  is  limited  to  defining  ISL  operational  characteristics  arising 
from  the  constraints  and  operations  of  the  various  entities  involved  in  achieving  satellite  mission 
objectives.  Satellite  mission,  spacecraft  subsystem  operational  details  and  mission  descriptions  are 
restricted  to  those  relevant  to  ISL  operation.  Payload  and  spacecraft  operations  and  command  and 
control  (C2)  descriptions  are  limited  to  those  relevant  to  ISL  operation.  Design  and  launch  segment 
constraint  impacts  on  ISL  operations  are  included. 

2.3  Approach 

An  operations  concept  is  defined  through  the  definition  of  a  technologically  stressing  ISL 
operational  scenario  of  an  ISL  application  in  an  actual,  planned  satellite  mission.  This  operational 
scenario  was  chosen  to  represent  an  extremely  broad  range  of  ISL  operations,  covering  near  term 
commercial-off-the-shelf  (COTS)  and  new  technology  challenging  ISL  implementations.  In  order  to 
confine  the  scope  of  this  operations  concept  to  ISL  operations  and  operational  characteristics,  only 
ISL  related  mission  operations  are  described. 

A  satellite  mission  overview  is  presented,  followed  by  a  description  of  ISL  related  operations  and 
constraints  from  the  following  mission  entities:  1)  spacecraft  subsystems,  2)  orbital  effects,  3) 
launch  vehicle  constraints  and  4)  program  design  constraints.  ISL  operations  are  then  presented  as  a 
summary  of  the  previous  mission  entity  related  ISL  operations  expanded  through  additional  ISL 
specific  design  constraints. 

2.4  Operational  Scenario  -  Distributed  Sparse  Aperture  Radar 

This  operational  scenario  describes  a  satellite  mission  using  eight  satellites  operating  as  distributed, 
space  based  radars  linked  to  form  one  large,  high  resolution  virtual  satellite  SAR  for  earth  surface  and 
earth  atmosphere  observation  missions.  This  scenario  is  chosen  as  the  worst  case  ISL  operational 
scenario  in  that  a  distributed,  satellite  SAR  LAN  is  deemed  as  a  most  technologically  challenging  ISL 
example.  This  mission  poses  a  number  of  technological  challenges  to  ISL  operational  characteristics 
and  ISL  implementation. 

2.4.1  Mission  Overview 

A  distributed,  satellite  based  SAR  mission  is  envisioned  with  clusters  of  eight  satellites  flying  in 
formation  at  ranges  of  a  few  meters  to  5000  km.  Each  satellite  is  identical  to  every  other  satellite  in 
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the  cluster.  Each  satellite  receives  radar  payload  sensor  data  and  must  share  some  or  all  of  that  data 
with  all  the  other  satellites.  In  the  worst  case,  each  satellite  must  receive  every  other  satellite’s 
entire  radar  payload  return  sensor  data.  The  entire  cluster  of  satellites  is  moved  from  one  orbital 
location  to  another  as  a  group,  in  order  to  perform  multiple  missions  of  covering  different  areas  on 
the  earth,  or  in  the  earth’s  atmosphere,  with  radar.  The  entire  satellite  cluster  operates  at  orbit 
altitudes  of  600-1000  km  witji  high  inclinations  of  50-90  degrees.  Figure  1  depicts  the  mission. 


Figure  1.  Distributed  SAR  Mission  Illustration  of  ISL  Based  Satellite  LAN 

ISL  related  operations  and  constraints  from  the  following  mission  entities  are  now  described: 

1 .  Spacecraft  Subsystems 

a)  Communications  And  Data  Handling  (C&DH) 

b)  Navigation 

c)  Payload 

2.  Orbital  Effects 

3 .  Launch  Vehicle  Constraints 

a)  Mass 

b)  Volume 

c)  Deployment 

4.  Program  Design  Constraints 

a)  Structure 

b)  Power 

c)  Cost. 

2.4.2  Spacecraft  Subsystems 

Although  spacecraft  are  composed  of  a  number  of  subsystems,  the  range  of  ISL  operational  impacts 
is  encompassed  by  the  operations  and  characteristics  of  three  major  subsystems:  C&DH,  navigation 
and  the  payload. 

2. 4. 2.1  Communications  and  Data  Handling 

The  C&DH  subsystem  of  the  distributed,  satellite  based  SAR  mission  provides  downlink  spacecraft 
payload  telemetry  reporting,  subsystem  status  telemetry  reporting,  satellite  cluster/LAN  time 
synchronization  and  C2.  Two  downlinks  exist.  One  downlink  is  via  ground  stations  to  a 
geostationary  Earth  orbit  (GEO)  communications  satellite  transmitting  to  each  of  the  spacecraft  in 
the  satellite  cluster  or  LAN.  An  additional  downlink  using  the  radar  payload  antennas  to  transmit 
information  is  also  provided.  The  ISLs  are  decoupled  from  the  communications  uplink  and  downlink 
subsystem  in  that  ISLs  are  not  used  for  interfacing  to  the  ground  station  or  other  data  recipients 
below  the  satellite  cluster.  The  C&DH  subsystem  is  a  separate  subsystem  from  the  ISL  subsystem. 
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2.  4. 2.7. 7 _ Payload^  Telemetry 

The  radar  payload  provides  radar  return  processing  results  to  the  ground  via  the  C&DH  ground  links. 
The  radar  processing  occurs  onboard  the  satellites  and  hence  only  a  small  portion  of  the  collected 
radar  return  data  is  downlinked  as  payload  data.  Since  ISLs  are  not  used  for  downlinking  payload  data, 
further  payload  telemetry  details  are  beyond  the  scope  of  this  operations  concept.  ISLs  may  be  able 
to  make  use  of  an  interface  to  the  payload  telemetry  data  within  the  C&DH  subsystem  to  perform 
ISL  optimizations  and  error  handling. 

2.-L2.7.2 _ Status  Telemetry 

Subsystem  status  information,  including  payload  subsystem  status  data,  e.g.,  voltage  levels, 
temperatures  and  setting  indicators,  is  also  downlinked  via  the  C&DH  subsystem.  Such  data  is 
typically  in  the  kbps  range.  Once  again,  since  ISLs  are  not  used  for  subsystem  status  telemetry 
downlinking,  further  details  are  not  required.  ISLs  may  be  able  to  make  use  of  an  interface  to  the 
subsystem  status  telemetry  data  within  the  C&DH  subsystem  to  perform  ISL  optimizations  and  error 
handling. 

2.4.2.7.3  _ Time  Synchronization 

The  ISL  in  conjunction  with  the  C&DH  system  is  expected  to  provide  satellite  position  and  ranging 
information  for  the  radar  data  processing  component  of  the  payload  subsystem.  The  position  and 
ranging  data  may  be  derived  from  internal  spacecraft  clocks  augmented  or  backed  up  with  Global 
Positioning  Satellite  (GPS)  transmissions.  The  ISL  system  must  therefore  be  able  to  receive  and 
decode  carrier  phase  differential  GPS  transmissions  or  be  able  to  receive  differential  GPS  data  from 
another  subsystem  such  as  the  C&DH  subsystem.  Differential  GPS  data  and  payload  data 
transmissions  between  satellites  via  the  ISLs  are  to  be  used  to  derive  20  ps  satellite  cluster  timing 
synchronization  and  3  mm  satellite  relative  position  determination.  The  high  accuracy  time 
synchronization  and  ranging  requirements  (20  ps  and  3  mm)  derive  from  the  need  to  synchronize  the 
clocks  and  payload  data  processing  onboard  all  satellites.  The  timing  and  ranging  calculations  are 
envisioned  to  be  performed  by  the  ISL  subsystem  and  passed  on  to  the  C&DH  subsystem.  Ranging 
data  is  also  used  to  support  navigation  subsystem  collision  avoidance  operations. 

2.4.2.7.4  _ Command.  And_  Control 

C2  consists  mainly  of  uplinked  commands  for  mission  positioning  and  mission  execution  timing. 
Commands  for  subsystem  components  are  also  available  to  the  extent  permitted  by  the  subsystem 
design.  Payload  uploads,  such  as  new  processing  algorithms  or  processing  algorithm  modifications, 
may  be  accomplished  via  the  C&DH  C2  subsystem  or  via  ISLs.  If  payload  uploads  are  not 
accomplished  via  C2  operation,  then  ISLs  would  require  a  payload  upload  operational  capability, 
discussed  under  payload  operations.  Initiation,  suspension,  resumption  and  termination  of  payload 
uploads  and  downloads  are  expected  to  be  C2  operations.  C2  data  rates  are  nominally  in  the  kbps 
range.  Since  ISLs  are  not  used  for  C2  uplinking,  further  C2  details  are  not  required.  ISLs  may  be  able 
to  make  use  of  an  interface  to  the  C2  portion  of  the  C&DH  subsystem  in  order  to  perform  C2  uplink 
backup  operations  and  error  handling. 

2. 4. 2. 2  Navigation 

The  navigation  subsystem  is  responsible  for  position/attitude  determination  and  control.  Since  the 
mission  operation  requires  the  cluster  of  eight  satellites  to  be  within  a  minimum  of  several  meters  to 
a  maximum  of  5000  km,  the  range  accuracy  to  each  neighbor  in  the  cluster  is  desired  to  3  mm.  To 
achieve  this  high  degree  of  accuracy  for  collision  avoidance  and  cluster  formation  preservation,  the 
navigation  subsystem  will  most  likely  transmit  position  related  information  between  satellites.  ISLs 
would  be  used  to  transmit  this  information.  The  navigation  subsystem  can  perform  satellite  attitude 
control  to  ±  5  degrees,  with  attitude  determination  to  0.02  degrees.  A  data  rate  of  several  kbps  is 
therefore  assumed  to  be  transmitted  by  the  ISLs  for  cluster  management.  In  addition,  ISLs  are 
assumed  to  be  used  to  transmit  high  accuracy  position  data  between  all  the  satellites  just  before  and 
during  mission  execution  time.  Because  of  the  importance  and  accuracy  requirements  of  high 
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accuracy  position  data,  a  bit  error  rate  of  10'12  for  transmission  of  pre-mission  position  data  is  a 
desired  ISL  operational  mode  with  a  bit  error  rate  of  10"6  being  a  minimum.  The  satellite  geometry  is 
changing  fairly  slowly,  and  under  the  influence  of  largely  predictable  forces.  During  non-operational 
(radar)  periods,  cluster  management  ISL  communications  could  be  spaced  minutes  apart.  During  radar 
operation,  the  geometry  updates  must  be  more  frequent  since  the  error  allowance  is  much  smaller. 
Rough  calculations  show  that /orbital  perturbations  cause  relative  drifts  of  50  m  over  4  hours. 
However,  these  perturbations  are  predominantly  due  to  known  effects  and  could  be  predicted/tracked 
easily,  thus  relaxing  the  update  requirement.  As  a  result,  for  a  3  mm  position  knowledge  requirement, 
ISL  position  updates  may  be  required  to  be  transmitted  every  second.  With  a  10-20%  mission  duty 
cycle,  the  ISL  pre-mission  position  data  transmission  operation  is  expected  to  make  up  only  1%  of 
ISL  transmissions. 

Either  extrapolation  of  ISL  transmission  of  differential  GPS  position  data  or  ISL 
transmission  radio  frequency  (RF)  phase  shift  information  will  be  used  by  the  ISL  subsystem  to 
calculate  timing  and  position  accuracy.  If  timing  data  is  output  by  the  ISL  to  the  navigation,  C&DH 
and  payload  subsystems,  an  ISL  timestamp  function  with  enough  bits  to  provide  picosecond  accuracy 
will  be  required.  Additionally,  the  timestamp  extraction  by  other  subsystems  must  be  with  less  than 
20  ps  variation,  or  jitter.  If  the  ISL  subsystem  outputs  only  a  timing  signal,  then  a  20  ps  timing 
signal  interface  must  be  provided  between  the  ISL  and  other  subsystems,  such  as  the  navigation 
subsystem.  If  position  data  is  output  by  the  ISL,  then  other  subsystems  such  as  the  navigation, 

C&DH  and  payload  subsystems,  will  require  an  ISL  position  data  interface.  Using  the  ISL  to  derive 
time  synchronization  and  position  determination  for  all  spacecraft  navigation  and  payload 
operations  will  necessitate  a  number  of  ISL  internal  and  interface  functions  and  will  restrict  ISL 
implementation  options. 

The  navigation  subsystem  can  be  used  to  yaw  steer  the  satellites.  Such  a  navigation 
subsystem  operational  capability  assures  that  all  satellites  present  the  same  structural  view  to  all 
satellites  at  all  times.  With  yaw  steering,  all  satellites  can  always  see  the  same  side  or  view  of  all 
other  satellites.  For  ISL  operation,  always  presenting  the  same  view  to  all  other  satellites  can 
facilitate  the  placement  and  pointing  operations  of  link  transmitter  antennas,  waveguides,  or  lasers. 

The  navigation  subsystem  is  responsible  for  maintaining  the  satellite  cluster  management  and 
LAN  physical  topology.  The  cluster  of  satellites  may  be  arranged  in  a  ring,  star,  torus  or  other 
topology  where  no  one  satellite  is  allowed  to  have  ISL  operational  modes,  capabilities  or  equipment 
different  from  any  other  satellite.  The  SAR  mission  cluster  is  typically  arranged  in  a  ring  topology. 
Cluster  or  LAN  topology  affects  ISL  operation  in  a  significant  manner.  As  long  as  the  payload 
required  data  rates  for  the  ISLs  can  be  met,  an  ISL  friendly  topology,  within  the  navigation 
subsystem’s  operational  tolerances,  should  be  selected  for  mission  operations.  Friendly  topologies 
making  for  less  difficult  ISL  operations  and  implementations  include  coplanar  orbits,  circular  orbits, 
non  line-of-sight  (LOS)  obscurations,  yielding  low  Doppler  shifts  and  relative  velocities.  Choosing 
an  ISL  friendly  topology  simplifies  ISL  operation  and  implementation. 

2.4. 2. 3  Payload 

The  radar  payload  on  each  satellite  within  the  cluster  operates  at  10  GHz.  The  radar  has  two  modes. 
In  one  mode,  ground  moving  target  indication  (GMTI),  the  bandwidth  is  20  MHz  and  in  the  synthetic 
aperture  radar  (imaging)  mode  the  bandwidth  is  500  MHz.  In  the  latter  mode,  little  exchange  of  data 
between  satellites  is  expected.  The  driving  case  for  the  ISL  throughput  is  expected  to  be  GMTI 
mode.  During  radar  return  reception,  the  receive  signal  is  digitized,  not  keeping  track  of  separate 
pulses.  In  the  worst  case,  where  all  satellites  receive  all  the  radar  return  data  from  all  other  satellites, 
ISL  communication  would  require  transmitting  the  following  number  of  bits  on  each  ISL: 

500  MHz/radar  pulse  (radar  intermediate  frequency  -  IF  bandwidth)  x  Nq  (Nyquist  sampling  rate 

of  2  samples/Hz  plus 

10%  margin  for  2.2  samples/Hz)  x  D  (digitization  bits/sample). 
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ISL  processing  at  one  satellite  would  have  to  accommodate  the  reception  of  N-l  (total  number  of 
satellites  minus  1)  times  the  number  of  bits  above: 

(N-l)  x  P  pulses/sec  x  500  MHz/pulse  x  2.2  samples/Hz  x  D  bits/sample. 

Table  1  summarizes  a  number, of  ISL  operational  data  rate  possibilities. 


Table  1.  Distributed  SAR  Payload  ISL  Data  Rate  Calculations 


|  Payload  ISL  Data  Rates  j 

Radar 

Nyquist 

Digitization 

Total  #  of 

Number  of 

Payload 

Sampling 

levels  =  2°  bits 

Bits/sec 

satellites 

ISL  bits 

Bandwidth 

Rate 

D 

transmitted  by 

minus  1 

received  at 

Nq 

each  satellite 

each  satellite 

(MHz) 

(samples/Hz) 

(D  bits/sample) 

(Mbps) 

_ m 1 _ 

(Gbps) 

1  GMTI  Mode  -  J 

500 

2.2 

8 

8800 

2 

17.6 

500 

2.2 

8 

8800 

7 

61.6 

500 

2.2 

12 

13200 

2 

26.4 

500 

2.2 

12 

13200 

7 

92.4 

1  Imaaina  Mode  - 1 

20 

2.2 

8 

352 

2 

0.704 

20 

2.2 

8 

352 

7 

2.464 

20 

2.2 

12 

528 

2 

1 .056  1 

20 

2.2 

12 

528 

7 

3.696 

As  can  be  seen  from  Table  1,  ISLs  must  support  a  high  transmission  data  rate  and  an  even  higher  data 
reception  rate.  Assuming  that  the  distributed  SAR  radar  algorithms  on  each  satellite  can  be  developed 
to  require  only  a  portion  of  complete  radar  data  from  the  other  satellites,  then  the  ISLs  between 
satellites  need  to  transmit  much  less  than  the  worst  case  528  Mbps.  Assuming  a  best  case  of  a 
minimum  of  100  Mbps  of  radar  data  transmission  for  algorithm  processing,  this  bounds  the  ISL 
transmission  operation  at  between  100  -  528  Mbps.  These  rates  still  require  N-l  times  the  amount 
of  ISL  receive  capacity,  or  a  range  of  700  Mbps  to  3.7  Gbps.  Given  that  this  mode  of  payload  data 
transmission  is  10-20%  of  the  total  ISL  operational  time  (duty  cycle  or  mission  execution  time), 
then  the  ISLs  must  have  a  peak  capacity  of  100  -  528  Mbps  for  transmission  and  0.7  -  3.7  Gbps  for 
reception  that  must  be  sustained  for  10-20%  of  the  life  span  of  the  satellites.  Payload  data 
transmissions  are  required  to  have  a  bit  error  rate  of  less  than  or  equal  to  10  . 

In  conjunction  with  radar  payload  processing,  SAR  algorithm  processing  distribution  impacts 
ISL  operation.  If  the  amount  of  data  to  be  transmitted  via  ISLs  for  SAR  algorithm  processing  is 
reduced  by  sending  different  subsets  of  radar  return  data  to  different  satellites,  the  ISL  link  operation 
must  include  addressing  operations. 

One  broadcast  transmission  per  satellite  could  contain  all  the  radar  return  data  from  that 
satellite,  with  different  pieces  of  the  data  identified  or  tagged  for  different  recipient  satellites.  In  this 
case,  a  single  ISL  from  each  satellite  would  broadcast  all  data  from  that  satellite  in  one  message  to  all 
other  satellites.  In  this  case,  the  ISL  transmission  rate  would  need  to  be  the  lowest  processing 
algorithm’s  data  reception  time  limit,  minus  some  propagation  delay  and  processing  time,  divided  by 
the  sum  of  all  the  number  of  bits  required  by  all  other  satellite  algorithms.  Figure  2  depicts  broadcast 
ISL  operation  within  a  cluster  of  eight  satellites. 

Seven  simultaneous  transmissions  per  satellite  could  be  made  to  transmit  different  data  to 
different  satellites.  Each  transmission  would  only  require  a  maximum  of  1/7  of  the  total  data  and 
data  rate  of  a  single  ISL  transmission.  Possibly  seven  transmitters  and  possibly  seven  receivers  may 
be  required.  A  single  transmitter  and  receiver  could  implement  seven  different  virtual  channels 
through  the  use  of  Wave  Division  Multiplexing  (WDM)  in  optical  systems,  or  through  the  use  of 
seven  different  correlation  codes  in  CDMA  RF  systems. 
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Figure  2.  Broadcast  ISL  LAN  Cluster  Operation 

Seven  sequential  transmissions  could  be  made  to  transmit  different  data  to  different  satellites. 
The  data  rates  would  either  have  to  be  seven  times  that  of  a  single,  broadcast  ISL  transmission  rate, 
or  the  algorithm  processing  time  would  have  to  be  extended  by  a  factor  of  seven.  Figure  3  depicts  a 
completely  connected  ISL  topology  with  seven  transmissions  per  satellite,  yielding  the  maximum 
number  of  28  bi-directional  links. 


Figure  3.  Distributed  SAR  Mission  Maximum  Number  Bi-Directional  ISL  Operation 


With  a  satellite  cluster  where  every  satellite  is  connected  to  every  other  satellite,  there  are 
N(N-1)  maximum  number  of  unidirectional  ISLs,  where  N  is  the  number  of  satellites.  With  eight 
satellites,  there  are  8  x  (8-1),  or  56  ISLs.  If  each  link  is  bi-directional,  there  are  N(N-l)/2,  or  28 
maximum  bi-directional  ISLs. 

Finally,  combinations  of  the  previous  three  transmission  operational  modes  could  be 
employed  for  ISL  operation.  For  example,  one  broadcast  transmission  could  be  made  to  supply  the 
data  to  three  other  satellites  and  another  transmission  could  be  made  (either  simultaneously  or 
after  the  first)  to  provide  the  data  to  the  remaining  four  satellites.  Depending  upon  the  data  and 
timing  needs  of  the  algorithms  on  different  satellites,  ISL  operation  may  be  composed  of 

1 .  A  single  transmission  of  all  data  to  all  other  satellites  (broadcast  mode) 

2.  Multiple  simultaneous  transmission  to  all  other  satellites  (point-to-point  mode) 

3.  Multiple  sequential  transmission  to  all  other  satellites  (point-to-point  mode) 

4.  Combinations  of  the  previous  three  (e.g.,  multicasting  mode). 

Case  1  gives  rise  to  the  least  number  of  ISLs.  Only  eight  broadcast  type  ISLs  are  required  for  all  eight 
satellites  to  communicate  with  one  another,  where  all  data  from  each  satellite  is  contained  in  one 
transmission,  regardless  of  whether  all  the  data  in  a  single  ISL  is  used  by  a  receiving  satellite.  Cases  2 
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and  3  give  rise  to  the  maximum  number  of  ISLs,  either  28  bi-directional  or  56  unidirectional  links. 
Case  4  can  give  rise  to  a  number  of  ISLs  between  case  1  and  cases  2  and  3,  8-56  uni-directional  or 
8-28  bi-directional  links.  Acknowledgments,  error  handling  and  other  protocol  handshaking  replies 
to  messages  can  either  be  piggybacked  unto  the  next  message  transmissions,  radar  data  transmissions 
or  non  radar  data  messages  such  as  navigational  or  C2  messages,  or  sent  as  separate  messages. 

It  is  also  possible  to  filter  SAR  algorithm  processing  based  on  the  operational  limitations  of 
the  ISLs,  as  opposed  to  altering  ISL  operation  based  on  SAR  limitations.  The  most  technologically 
challenging  to  implement,  whether  distributed  SAR  algorithm  processing  or  ISL,  will  drive  the 
operation  of  the  other. 

Payload  uploads,  such  as  new  processing  algorithms  or  processing  algorithm  modifications, 
could  be  accomplished  via  ISLs.  The  ISL  receivers  could  be  used  to  transmit  payload  uploads.  If  this 
is  the  operation  for  payload  uploads,  the  ISLs  would  have  to  be  able  to  accomplish  command 
validation,  verification  and  authentication,  or  be  able  to  interface  to  the  C&DH  system  for 
performance  of  these  functions.  In  addition,  ISL  receivers  would  have  to  be  interoperable  with 
payload  upload  transmission  equipment.  ISL  receive  components  would  have  to  have  additional 
interfaces  to  payload  subsystem  components  used  for  storing  processing  algorithms.  Since  the  ISLs 
are  used  some  of  the  time  for  low  rate  navigation  collision  avoidance  and  orbit  maintenance  data 
transmissions,  simultaneous  reception  of  payload  uploads  with  navigational  data  seems  a  likely  mode 
of  ISL  operation.  If  the  C&DH  system  is  used  to  perform  payload  uploads,  the  ISL  would  not  require 
simultaneous  ISL  and  ground  link  operation.  ISL  interoperability  with  upload  equipment  would  also 
not  be  required.  ISL  to  payload  subsystem  interfacing  would  also  be  simplified. 

During  80-90%  of  non  radar  data  transmission  operations,  payload  operations  require  only 
occasional  status  information  and  perhaps  processing  algorithm  uploads.  Payload  status  information 
is  not  transmitted  or  received  via  the  ISLs.  As  mentioned  in  the  Status  Telemetry  section  above, 
ISLs  may  be  able  to  make  use  of  an  interface  to  the  payload  subsystem  status  telemetry  data  to 
perform  ISL  optimizations  and  error  handling. 

2.4.3  Orbital  Effects 

Orbital  altitudes,  shapes  and  orbit  inclinations  have  an  impact  on  ISL  operations,  particularly  when 
combined  with  satellite  LANs  or  clusters  where  the  satellites  to  be  linked  are  in  different  orbital 
planes  or  in  non-circular  orbits.  At  LEO  altitudes  of  600  -  1000  km  and  at  high  orbital  inclinations 
of  50  -90  degrees,  all  eight  satellites  travel  at  relatively  high  velocities  to  one  another  unless 
constant  changes  in  velocity  (delta- V)  are  made.  The  distributed  SAR  mission  uses  spacecraft 
thrusters  sparingly  to  maintain  a  tight  cluster  spacing  of  a  nominal  100  m  separation  between 
satellites. 

Intersatellite  range  rates  of  <  1  m/s  are  to  be  maintained.  Given  such  low  intersatellite 
distances  and  range  rates,  ISL  receivers  and  transmitters  do  not  have  to  deal  with  high  relative 
velocities  and  large  amounts  of  Doppler  shift  (or  variations  in  Doppler  shift)  in  data  transmissions. 

Using  yaw  steering  with  the  low  relative  velocities  and  Doppler  shifts,  in  conjunction  with 
the  close  spacing  of  the  satellites  in  the  cluster,  it  may  be  possible  to  use  fixed  antennas  or  optical 
components  for  ISL  transmitting  and  receiving.  The  satellite  cluster  would  act  as  if  all  satellites  are 
in  a  single  orbital  plane,  making  for  the  case  of  intraplane  communication  where  the  satellites  will 
always  be  in  the  same  position  relative  to  one  another.  The  LOS  paths  between  these  satellites  will 
not  change  angle  and  length  significantly  avoiding  the  added  complications  of  interplanar 
communications  and  non  circular  orbits:  a)  high  relative  velocities  between  the  satellites,  b)  tracking 
control  problems  as  antennas  must  slew  around  and  high  Doppler  shifts.  This  can  be  considered  a 
result  of  Kepler’s  second  law,  where  equal  areas  of  arc  of  the  orbital  plane  are  swept  out  in  equal 
times.  With  elliptical  orbits,  a  satellite  would  see  the  relative  positions  of  satellites  ahead  and  behind 
appear  to  rise  or  fall  considerably  throughout  the  orbit,  and  controlled  pointing  of  the  fore  and  aft 
intraplane  link  antennas  would  be  required  to  compensate  for  this.  For  the  distributed  SAR  mission, 
all  eight  satellites  are  assumed  to  behave  as  if  they  are  in  the  same  orbital  plane.  Sparingly  using 
thrusters  to  make  for  a  satellite  cluster  with  circular  orbit  characteristics,  avoids  ISL  complications 
arising  from  non  circular  orbits. 
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As  the  cluster  of  satellites  moves  in  a  group  from  one  mission  location  to  another,  orbital 
mechanics  and  navigation  subsystem  limitations  may  cause  one  satellite  to  obstruct  the  LOS  between 
two  other  satellites.  With  the  potential  orbital  effect  of  LOS  obscuration,  a  number  of  new  potential 
ISL  operations  may  be  required.  The  ISL  subsystem  may  have  to  have  an  interface  to  the  navigation 
system  to  avoid  LOS  obscuration  or  to  be  notified  of  impending  LOS  obscuration.  The  ISL  may  be 
required  to  sense  obscuration/ through  bit  error  rate  increases  or  loss  of  link  connection.  ISL 
operations  may  require  routing  of  messages  through  other  satellites  in  order  to  reach  a  satellite  not  in 
LOS.  ISL  operations  may  have  to  include  a  redundant  non  LOS  transmission  mode  and 
communications  equipment  for  times  of  LOS  obscuration.  If  LOS  obscuration  data  transmission 
outages  are  not  acceptable,  then  ISL  operation  may  have  to  be  via  non  LOS  transmissions,  e.g.,  RF  as 
opposed  to  optical. 

ISL  operation  and  implementation  is  very  much  dependent  upon  orbital  effects,  particularly 
orbit  types  and  inclinations,  and  LOS  obscuration.  Assuming  that  the  distributed  SAR  mission  cluster 
has  circular  type  orbits,  interplanar  communications  only  and  no  LOS  obscurations,  fixed  antenna 
and  optical  ISL  operations  can  be  employed. 

2.4,4  Launch  Vehicle  Constraints 

The  launch  vehicle  chosen  for  lifting  the  satellites  into  orbit  places  a  number  of  physical  restrictions 
on  the  ISL  subsystem  which  can  severely  effect  the  implementation  options,  and  hence  the 
operation,  of  ISLs. 

2.4.4. 1  Mass 

Mass  restrictions  include  a  total  satellite  mass  of  <  100  kg.  Of  that  100  kg,  a  maximum  of  5  kg  have 
been  allocated  for  the  ISL  subsystem  operation  and  implementation. 


2. 4. 4. 2  Volume 

Volume  inside  launch  vehicles  is  limited.  The  desired  launch  vehicle,  stowed,  volume  of  each  satellite 
within  the  cluster  is  approximately  0.3  m3.  Of  this  volume,  <  0.02  m3  is  allocated  for  the  ISL 
subsystem. 


2. 4. 4. 3  Deployment 

Satellites  can  increase  their  volume  over  their  launch  vehicle  volume  through  deployment  of 
expandable  structures  and  components  after  separation  from  the  launch  vehicle.  Restrictions  exist  to 
limit  the  maximum  size  of  even  deployed  satellites.  Orbital  speeds,  slewing  rates,  payload  and 
subsystem  operational  characteristics  and  other  factors  limit  the  deployed  size  of  the  distributed  SAR 
satellites  to  approximately  4  m3. 

Given  an  expansion  volume  from  0.3  m3  in  a  stowed  launch  vehicle  configuration  to  a 
deployed,  operational  volume  of  4  m3,  the  implication  for  ISL  operation  is  that  the  ISL  subsystem 
must  accommodate  compression  or  collapsing  for  launch  and  expansion  for  deployment.  Assuming  a 
final  deployed  satellite  volume  and  shape  as  depicted  in  Figure  4,  the  ISL  subsystem  can  have  an 
expansion  factor  of  about  20  in  height,  with  a  shape  that  conforms  to  that  of  the  satellite’s  shape. 


Figure  4.  Deployed  Distributed  SAR  Satellite  Volume  and  Shape 
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A  size  and  shape  of  4  m  in  height,  1.2  m  in  width  and  1.2  m  in  breadth,  is  therefore  a  reasonable 
operational  constraint  for  deployed  ISL  operation. 

2.4.5  Program  Design  Constraints 

A  number  of  SAR  program  factors,  such  as  pre-existing  conditions  (e.g.,  use  of  development 
standards,  Federal  Communications  Commission  -  FCC  regulations,  etc.),  organizational  issues,  safety 
(e.g.,  collateral  damage  to  other  satellites),  risk  and  cost  management,  and  political  factors,  give  rise 
to  an  additional  set  of  restrictions  on  ISL  operations  and  implementations.  Three  such  program 
design  constraints  have  the  bulk  of  ISL  operational  impacts:  structure,  power  and  cost. 

2.4.5. 1  Structure 

The  deployable  nature,  multifunctional  structures,  smart  mechanisms,  thin  film  photovoltaics, 
micro-electro-mechanical  components  and  advanced  electronics  packaging  of  the  distributed  SAR 
mission  satellites  influence  ISL  operation  and  implementation  choices.  ISL  operations  cannot 
damage  or  weaken  the  structure.  For  example,  as  a  deployable,  mechanical  structure,  high  slewing 
rates  of  a  large  ISL  link  antenna  would  not  be  acceptable. 

2.4. 5. 2  Power 

Power  limitations  necessitate  a  power  budget  for  the  ISL  subsystem.  A  power  budget  of  <  20  W  has 
been  allotted  for  ISL  operation.  The  ISL  cannot  contaminate  the  electrical  ground  of  the  payload  or 
other  subsystem  electronics. 

2. 4. 5. 3  Cost 

Cost  limitations  have  been  placed  on  the  ISL  subsystem.  A  cost  of  <  $300K,  per  ISL  subsystem  in 
quantities  of  300  units  has  been  levied  on  the  ISL  subsystem.  Operational  limitations  for  the  ISL 
subsystem  will  arise  as  a  result  of  cost  limitations  restricting  implementation  options. 

2.4.6  ISL  Operations 

ISL  operations  arising  from  other  mission  entity  operations,  described  in  previous  sections,  are 
summarized  in  this  section  and  additional  ISL  operations  are  described.  The  main  ISL  operations 
arise  out  of  the  need  to  support  distributed  SAR  payload  algorithm  processing.  This  is  emphasized  ^ 
through  the  use  of  a  separate  C&DH  subsystem  for  payload  and  status  telemetry  downlinking,  and  C 
uplinking  and  downlinking.  An  interface  between  the  C&DH  and  ISL  subsystems  would  provide  for 
potential  ISL  operations  to  back  up  the  C&DH  downlink  and  uplink  operations.  A  possible  ISL  and 
C&DH  operation  of  sharing  components  between  the  ISL  and  C&DH  system  may  be  an  operational 
mode  used  to  assure  ISL  operation  with  ground  link  hardware,  or  to  provide  a  degraded  mode  of  ISL 
operation. 

The  most  weighty  ISL  operation  is  payload  data  transmission  on  ISLs.  Data  rates  for 
payload  data  transmission  on  ISLs  are  in  the  range  of  100  -  528  Mbps,  with  a  single  satellite  faced 
with  receiving  this  number  of  bps  from  each  of  the  other  satellites  for  a  total  ISL  receive  rate  of 
0.7  -  3.7  Gbps.  This  payload  data  rate  accounts  for  10-20%  of  ISL  operation.  ISLs  are  expected  to 
be  transmitting  navigational  data  (including  differential  GPS  data)  providing  a  constant  bit  rate  data 
stream  of  several  kbps. 

Whether  the  ISL  transmission  carrier  and  signal  phase  delays  or  ISL  differential  GPS 
calculations  and  data  transmissions  are  used  by  the  ISL  subsystem  to  calculate  timing  and  position 
accuracy,  interfaces  to  other  subsystems  using  timing  and  position  information  need  to  be  provided. 
If  timing  and  position  data  is  output  by  the  ISL  to  the  navigation,  C&DH  and  payload  subsystems,  an 
ISL  data  insertion  and  interface  function  with  enough  bits  to  provide  picosecond  and  millimeter 
accuracy  will  be  required.  Additionally,  the  data  extraction  by  other  subsystems  must  be  with  less 
than  20  ps  variation,  or  jitter.  If  the  ISL  subsystem  outputs  only  a  timing  signal,  then  a  20  ps  timing 
signal  interface  must  be  provided  between  the  ISL  and  other  subsystems,  such  as  the  navigation 
subsystem.  Using  the  ISL  to  derive  time  synchronization  and  position  determination  for  all 
spacecraft  navigation  and  payload  operations  will  necessitate  a  number  of  ISL  internal  and  interface 
functions  and  will  restrict  ISL  implementation  options.  Since  cluster  management  and  potentially 
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GPS  navigational  data  is  constantly  transmitted  over  the  ISLs,  payload  data  insertion  and  extraction, 
and  timing  and  position  determination  will  have  to  be  performed  simultaneously. 

Payload  uploads  might  be  via  ISL  operation.  The  ISL  subsystem  would  have  to  be  able  to 
accomplish  command  validation,  verification  and  authentication,  or  be  able  to  interface  to  the 
C&DH  system  for  performance  of  these  three  command  functions.  ISL  receivers  would  have  to 
interoperate  with  payload  uplpad  source  transmission  equipment  and  interface  to  payload  subsystem 
components  for  storing  processing  algorithms.  ISLs  would  have  to  have  a  dual  receive  mode  where 
transmission  from  other  ISLs  and  payload  uploads  could  be  received  simultaneously. 

2.4.7  Additional  ISL  Design  Constraints 

Additional  ISL  design  constraints  provide  additional  ISL  operational  characteristics.  For  any  mission, 
ISL  operation  cannot  interfere  with  payload  operations.  As  a  necessity  for  the  SAR  mission,  ISL 
operation  cannot  interfere  with  the  radar  receivers.  This  provides  an  operational  constraint  for  ISLs 
to  have  interference  with  radar  receivers  of  <  30  decibels  relative  to  1  W  (dBW)  out  of  the  radar 
band  of  10  GHz  ±500  MHz  and  <  -210  dBW  in  the  radar  band  of  10  GHz  ±500  MHz.  This  would  rule 
out  virtually  all  ISL  RF  operation  near  10  GHz.  ISL  operation  shall  adhere  to  standard  EMI/EMC 
levels  for  all  electronic  equipment  for  interference  with  other  spacecraft  subsystems  and  ISL 
operation. 

With  a  minimum  number  of  eight  and  a  maximum  number  of  28  (bi-directional)  ISLs 
operating  simultaneously,  ISL  transmissions  must  not  interfere  with  one  another.  In  the  case  of 
broadcast  ISLs,  non  interference  implies  an  ISL  operational  mode  of  being  able  to  separate  seven 
other  satellite  transmissions  from  one’s  own  transmission.  In  the  case  of  multiple  ISL  transmissions 
per  satellite,  an  ISL  receiver  in  one  satellite  must  be  able  to  identify  the  links  addressed  to  this 
satellite  from  the  links  addressed  to  other  satellites.  When  every  satellite  has  an  ISL  to  every  other 
satellite,  link  address  selection  is  not  a  required  operation.  In  addition,  with  a  fully  interconnected 
LAN  communications  topology,  every  satellite  is  only  one  link  away,  avoiding  the  need  for  routing 
messages  through  one  or  more  satellite  to  reach  the  intended  recipient.  ISL  routing  operations  would 
only  be  required  if  LOS  obscuration  makes  direct  ISL  connection  impossible. 

The  useful  life  of  the  payload  radar  data  is  numbered  in  days,  implying  a  need  for  ISL 
transmission  security  in  the  form  of  encryption,  transmission  encoding,  e.g.,  frequency  hoping.  Code 
Division  Multiple  Access  (CDMA),  or  transmission  power  limitations  such  as  optical  or  spread 
spectrum  (i.e.,  CDMA)  operation.  ISL  transmission  security  needs  to  only  provide  protection  to  the 
degree  of  requiring  another  party  more  than  72  hours  to  break  the  protection  scheme  and  obtain  the 
data.  However,  breaking  the  ISL  security  scheme  once  must  not  lead  to  breaking  the  ISL  security^ 
method  in  less  time  on  subsequent  security  violation  attempts.  If  ISLs  are  used  to  communicate  C 
messages  or  commands,  whether  spacecraft  subsystem  or  payload  commands,  such  ISL  message 
transmissions  require  secure  ISL  operation.  ISL  security  for  C2  messages  requires  ISL  operation  such 
that  the  C2  commands  cannot  be  extracted  during  the  course  of  the  mission  life  of  the  entire  satellite 
cluster.  Recording  valid  ISL  C2  messages  and  playing  them  back  into  ISL  receivers  by  unauthorized 
parties  must  also  be  protected  against.  ISL  C2  transmissions  need  the  command  authorization, 
validation  and  verification  set  of  operations. 

It  is  not  expected  that  intentional  or  unintentional  jamming  occur  in  the  ISL  frequency  band. 
Should  a  jammer  operate  in  the  ISL  channel  frequencies,  the  mission  may  be  jeopardized  and 
therefore  some  form  of  ISL  jamming  protection  should  be  included  in  ISL  operation. 

Since  radar  data  formats  and  definitions  are  known  to  all  recipients  before  ISL  operations 
begin,  there  is  no  need  for  higher  layer  communication  protocols  to  be  part  of  ISL  communications 
protocol  operation.  Link  error  handling  and  security  operations  will  be  part  of  ISL  operation.  Data 
compression  may  be  an  ISL  characteristic,  depending  upon  ISL  data  rate  limitations  and  radar 
algorithm  processing  needs.  If  ISL  data  rates  are  unable  to  be  met  within  technology  and  design 
constraints,  then  ISL  data  rates  can  be  reduced  via  data  compression.  Radar  data  may  not  be 
compressible  enough  for  existing  compression  algorithms  to  warrant  the  ISL  resource  expenditure 
required  to  perform  compression  and  decompression.  Radar  algorithms  may  not  be  able  to  tolerate 
the  time  delays  of  compression  and  decompression  ISL  operations. 
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ISL  communications  should  be  initiated  automatically  by  cluster  or  LAN  formation  flying 
control  and  radar  payload  operational  mode.  The  navigation  subsystem  may  provide  information  to 
the  ISL  subsystem  to  initiate  ISL  operations  if  the  ISL  is  not  currently  active.  This  may  require  an 
ISL  preemptive  operational  capability,  if  other  ISL  transmission  or  test  operations  are  in  progress  at 
the  time  of  radar  data  transmission  initiation  requests.  The  ISL  may  need  to  sense  formation  flying 
control  initiation  through  internal  means,  such  as  noting  an  increase  in  navigation  data  transmissions 
or  noting  the  transmission  requests  for  particular  types  of  navigational  commands  or  data.  Radar,  or 
payload  operations  could  be  communicated  through  interfacing  with  the  radar  or  other  spacecraft 
subsystems  by  way  of  receiving  notification  of  radar  operations.  The  ISL  subsystem  could  detect 
current  or  impending  radar  operation  through  completely  independent  means  such  as  increased  noise 
levels  in  ISL  receivers. 

Each  ISL,  whether  one  or  more  per  satellite,  should  be  able  to  be  controlled  and  tested 
individually,  through  ground  command  or  self-test.  Individual  control  includes  an  ISL  operation  of 
routing  a  command  for  satellite  A  in  a  particular  way  to  satellite  B.  Individual  control  and  test  mode 
operations  are  therefore  part  of  ISL  functionality. 

For  all  ISL  operations  and  implementations,  a  technology  extrapolation  to  the  level  of  the 
year  2003  is  allowed.  Planning  on  what  should  be  available  in  the  year  2003  somewhat  eases  ISL 
operational  and  implementation  restrictions.  A  number  of  additional  design  constraints  may  surface 
during  the  course  of  ISL  development  and  implementation. 
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The  requirements  document  is  the  single  source  of  all  the  binding  conditions  on  any  implementation 
of  a  system  of  interest.  The  system  of  interest  is  a  set  of  ISLs,  an  ISL  system,  used  in  a  satellite 
LAN  or  satellite  LAN-like  application.  This  requirements  document  defines  the  characteristics  of 
ISLs  used  to  link  a  number  of  satellites  into  a  single  virtual  satellite  in  order  to  achieve  the  satellite 
mission  objectives.  This  requirements  document  provides  a  means  to  communicate  the  inputs, 
outputs  and  physical  constraints  of  ISLs  in  the  context  of  planned  and  foreseeable  satellite  missions. 
The  requirements  document  provides  a  single  source  of  system  requirements  for  organizations, 
individuals  and  systems  involved  with  ISL  system  specification,  development  and  test. 

3.1  Purpose 

The  purpose  of  this  requirements  document  is  to  define  and  document  the  set  of  ISL  requirements  for 
an  actual,  planned  satellite  mission,  TS21,  and  to  serve  as  the  requirements  source  for  evaluating 
wireless  communication  technologies  and  defining  recommended  ISL  implementations  capable  of 
conducting  planned  and  foreseeable  space  missions.  Additional  uses  for  the  requirements  document 
include  evaluating  future  proposed  ISL  implementations,  performing  cost  and  risk  tradeoffs  and 
gaining  user  community  acceptance  of  ISL  implementations.  The  requirements  document  also  serves 
to  define  the  ISL  system  boundaries. 

A  secondary  purpose  of  this  ISL  requirements  document  is  for  a  wide  range  and  number  of 
satellite  missions  with  satellite  LAN-like  interconnections  to  make  use  of  the  documented  ISL 
requirements.  This  ISL  requirements  document  provides  for  a  wide  range  of  ISL  applications  through 
the  definition  of  a  technologically  stressing  set  of  ISL  requirements  for  an  actual,  planned  satellite 
mission,  TS21.  High  data  rates,  spacecraft  subsystem  support,  stressing  volume,  weight,  power  and 
time  delay/processing  restrictions,  etc.,  should  allow  a  wide  range  and  number  of  satellite  missions  to 
make  use  of  this  ISL  requirements  document  for  the  above  stated  purposes. 

3.2  Scope 

The  scope  of  this  requirements  document  includes  ISL  characteristics  and  constraints  arising  from 
payload,  C2,  navigation  and  other  spacecraft  subsystem  operations  involving  or  otherwise  impacting 
ISL  operations.  The  scope  is  further  narrowed  to  a  satellite  mission  using  eight  satellites  operating  as 
distributed,  space  based  radars,  linked  to  form  one  large,  high  resolution  virtual  satellite  SAR.  Design 
and  launch  segment  constraint  impacts  on  ISL  characteristics  are  included.  Computer-Human 
Interface  (CHI)  characteristics  and  their  corresponding  requirements  are  not  specified  since  ISLs  are 
an  almost  completely  automated  spacecraft  subsystem  with  little  or  no  human  or  manual  control 
functions  and  operations. 

Requirements  validation,  verification  and  testing  are  outside  the  scope  of  this  document. 
However,  requirements  validation  and  verification  are  a  critical  part  of  providing  an  ISL  satellite 
subsystem  that  performs  all  needed  operations  in  the  required  manner.  Requirements  validation  and 
verification  can  be  performed  through  satellite  program  review  of  the  requirements  specified  in  this 
document.  Revisions  to  the  requirements  arising  from  satellite  program  office  review  can  be 
incorporated  into  a  revised,  validated  and  verified  ISL  requirements  document.  Requirements  testing 
has  been  addressed  to  the  extent  that  all  requirements  have  been  defined  in  such  a  manner  as  to  allow 
testing  through  analysis,  simulation  or  actual  tests.  An  effort  has  been  made  to  not  define 
requirements  that  cannot  be  tested. 

3.3  Approach 

The  requirements  are  identified  as  statements  specifying  the  capabilities  and  characteristics  that  the 
ISL  system  shall  have.  The  requirements  are  decomposed  into  one  requirement  per  requirement 
statement.  Individual  requirements  can  be  viewed  as  an  answer  to  a  question  about  the  ISL  system. 

The  ISL  requirements  are  derived  from  one  main  source,  the  ISL  Operations  Concept,  defined 
in  the  previous  section.  Secondary  sources  of  requirements  were  also  used:  existing  documentation 
used  in  defining  the  Operations  Concept  [C99,  G99],  technical  interchanges  between  relevant 
personnel  [TI99a-g]  and  the  SBIR  Program  solicitation  for  this  effort  [DoD99.1]. 
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In  order  that  the  defined  requirements  possess  the  necessary  requirement  qualities  of  Institute  of 
Electrical  and  Electronics  Engineers  (IEEE)  Standard  830-1998  “IEEE  Recommended  Practice  for 
Software  Requirements  Specifications”  and  to  facilitate  electronic  requirements  analysis  via 
Computer  Aided  System  Engineering  (CASE)  tools,  the  following  template  is  used  to  document  ISL 
requirements  in  this  document. 

1.  ID  / 

This  field  assigns  a  unique  numeric  requirement  identifier. 

2 .  Requirement 

This  field  provides  a  synopsis  of  the  requirement. 

3.  Category  . 

This  field  classifies  the  requirement  into  one  or  more  of  the  following  categories:  Functional, 
Data,  Interface,  Operational,  Constraint,  or  Other.  If  more  than  one  keyword  is  given,  the 
first  is  considered  the  primary  category  of  the  requirement  and  the  others  give  secondary 
associations. 

4.  Priority 

This  field  assigns  a  degree  of  necessity  to  the  requirement  as  mandatory,  optional  or  an  idea 
for  further  development. 

5.  Uncertainty 

This  field  quantifies  the  likelihood  of  the  requirement  changing,  with  a  10  defined  as  shall  not 
change  and  a  1  defined  as  certain  to  change. 

6.  Attribute_Other 

This  field  specifies  optional,  additional  requirement  attributes  via  attribute  keywords  such  as: 
Internal,  External,  Conflict  and  Quantitative. 

7 .  Source 

This  field  specifies  one  of  six  sources  of  the  requirement:  the  Operations  Concept  document 
[M99],  documentation  used  in  defining  the  Operations  Concept  [C99,  G99],  technical 
interchanges  between  relevant  personnel  [TI99a-g]  or  the  SBIR  satellite  LAN  contract 
solicitation  [DoD99.1].  Implied  or  derived  requirements  have  one  of  the  six  sources  of  direct 
requirements  listed  as  their  source. 

8 .  Reference 

This  field  cites  a  specific  page  and  paragraph  in  the  June  1999  Satellite  LAN  ISL  Operations 
Concept  document  as  a  reference  for  further  requirement  details. 

9.  Identified  By 

This  section  records  who  the  identifier  of  the  requirement. 

The  template  includes  requirement  categories  and  attributes.  A  category  is  simply  a  rough  division  or 
classification  of  the  requirement  which  has  an  important  place  in  the  requirements  identification 
process.  The  categories  are  chosen  with  a  view  towards  the  application  of  the  ISL  requirements  in 
the  later  steps  of  the  systems  engineering  methodology,  design,  development  and  test.  When 
analysts  return  to  this  document  with  specific  problems  in  mind  (e.g.,  the  construction  of  a  data 
dictionary  or  conceptual  design),  they  will  find  the  requirements  conveniently  sorted  (e.g.,  data 
requirements  are  in  a  separate  category).  Requirements  may  not  fit  completely  in  one  category.  In 
that  case,  it  is  necessary  to  decide  what  the  primary  category  is  and  assign  the  requirement  to  it.  The 
requirement  may  also  be  given  a  secondary  category  assignment.  One  may  search  the  requirements 
database  by  category  for  requirements  of  interest.  The  categories  used  for  requirements  specification 
in  this  document  are: 

1 .  Functional 

Requirements  about  what  the  ISL  system  shall  do  are  listed  under  this  category. 

2.  Data 

Requirements  specifying  details  about  information,  what  must  be  produced,  stored,  processed, 
or  interpreted.  Requirements  concerning  data  storage,  access  methods,  error  detection, 
distribution,  security,  protection  and  data  syntax  -  format  and  type  definitions  are  also  listed 
under  this  category. 
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3.  Performance 

Quantitative  requirements  about  any  aspect  of  ISL  system  performance,  including  how  fast, 
how  often,  what  detail  or  resolution,  capacity  reserves,  etc.,  are  listed  under  this  category. 
Requirements  concerning  data  input  or  output  devices  (payloads,  other  satellite  subsystem 
data  to  be  input  or  output  via  ISLs,  etc.)  and  their  performance  requirements,  including  data 
volumes  and  rates  are  also  listed  under  this  category. 

4.  Interface 

Requirements  regarding  connections  or  data  exchanges  between  pairs  of  entities  are  listed 
under  this  category.  External  interfaces  to  other  satellites,  ground  systems  and  spacecraft 
subsystems  are  also  listed  under  this  category. 

5 .  Operational 

Requirements  regarding  how  the  ISL  system  is  going  to  be  used  (orbital  constraints,  etc.)  are 
listed  under  this  category.  Requirements  concerning  the  interaction  of  the  user  with  the  ISL 
system  are  outside  the  scope  of  this  document  but  could  be  placed  into  this  category. 

6.  Constraint 

Requirements  concerning  restrictions  imposed  by:  pre-existing  conditions,  organizational 
impacts  to  be  minimized  or  avoided,  ease  of  use,  schedule  constraints,  use  of  COTS 
equipment,  FCC  regulations,  safety  (e.g.,  collateral  damage  to  other  friendly  satellites  or 
satellite  missions),  ISL  system  protection,  audit  trails,  maintainability,  configuration  and  risk 
management  (e.g.,  use  of  development  standards  from  IEEE,  American  National  Standards 
Institute  -  ANSI,  etc.),  ISL  system  fault  handling  and  fault  recovery,  and  non  data 
performance  considerations  (e.g.,  weight,  volume  and  power  constraints)  are  all  listed  under 
this  category.  This  category  includes  legal  and  political  requirements  (e.g.,  centralized  vs. 
distributed  control). 

The  categories  are  broad  requirement  classifications.  Requirement  classification  attempts  to  assign 
requirements  to  more  narrow,  more  specific  groups  or  classes.  The  template  therefore  includes 
requirement  attributes.  Attributes  further  classify  requirements  into  smaller  groups.  Attributes 
facilitate  requirements  validation,  verification,  analysis  and  testing  by  guiding  analysts  to  the 
relevant  requirements.  In  addition,  attributes  reduce  the  amount  of  information  that  must  be 
exchanged  between  analysts  and  personnel  in  requirements  related  meetings.  The  attributes  used  for 
requirements  specification  in  this  document  are: 

1 .  Internal 

This  attribute  applies  to  requirements  or  data  that  are  internal  to  the  ISL  system  with  no 
effect  (e.g.,  levies  no  implied  or  somewhat  hidden  requirements)  on  other  spacecraft  or 
ground  subsystems. 

2.  External 

This  attribute  applies  to  requirements  or  data  that  have  an  external  to  ISL  source,  sink  or 
impact  (e.g.,  levies  direct,  implied  or  somewhat  hidden  requirements)  on  other  spacecraft  or 
ground  subsystems. 

3.  Conflict 

This  attribute  applies  to  requirements  where  another  requirement  identified  with  this  attribute 
has  a  potential  conflict  with  this  requirement. 

4.  Quantitative 

This  attribute  applies  to  requirements  that  can  be  quantified  and  is  especially  interesting  from 
the  standpoint  of  performance  (e.g.,  response  time  and  capacity  measures). 

3.4  ISL  Requirements  Matrix 

The  following  pages  contain  the  ISL  requirements  in  table  format,  defined  according  to  the  template 
specified  above. 
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Table  2.  TS21  Requirements 


TS21  ISL  REQUIREMENTS 


The  ISL  system  shall:  _ 


1  transmit  radar  payload  data  at  a  rate  up  to  100  Mbps  for  a 

maximum  of  20%  of  on  orbit  time  to  two  other  satellites _ 


2  receive  radar  payload  data  at  a  minimum  rate  up  to  1 00  Mbps 
for  a  minimum  of  10%  and  a  maximum  of  20%  of  on  orbit  time 
from  two  other  satellites  simultaneously _ _ 


3  synchronize  satellite  cluster  ISL  clock  times  to  allow  satellite 
cluster  ranging  determinations  on  the  order  of  3  mm  (e.g., 
within  20  ps)  _  _ 


provide  satellite  cluster  ranging  information  for  3  mm)satellite 
position  accuracy  determination  with  the  use  of  ISL  external 
spacecraft  position  bounded  knowledge  (e.g.,  GPS) _ 


have  a  known  repeatable  data  latency  through  its  system 


6  have  a  loop-back  (transponder  or  echo)  mode  with  known 

latency  in  the  loop _ _ 


7  transmit  satellite  position  information  at  a  rate  not  to  exceed  D,P 
once  per  minute  during  non  radar  operation _ 


8  transmit  satellite  position  information  once  a  second  for  20%  of  D,P 
the  time  during  (radar  operations) _ __ 


calculate  link  bit  error  rates  _ 


transmit  satellite  position  information  with  bit  error  rate  of  10 


1 1  attempt  to  compensate  for  satellite  position  information  bit  F,P 

error  rates  greater  than  10 _ _ 

transmit  radar  payload  data  with  bit  error  rate  of  10 _ 


13  attempt  to  compensate  for  radar  payload  data  transmission  link  F,P 

-6 

error  rates  greater  than  10 _ 


14  perform  ISL  link  optimizations  to  include  bit  error  rates, 
transmit  power  and  transmission  time  _ _ 


erform  ISL  error  handlin 


determine  loss  of  links  or  link  connections _ _ 


operate  over  distances  up  to  5000  km  _ 


18  perform  data  compression  and  decompression  on 

transmissions  to  and  from  other  satellites _ _ 


19  transmit  to  satellites  in  any  direction  nominally  in  a  plane 

derived  from  stable  solutions  of  Hill’s  equations _ 


20  operate  in  the  presence  of  LOS  obstruction  between  the 
sending  and  receiving  satellite _ 


21  function  normally  in  the  presence  of  a  70  dBs  relative  to  1  W 
(dBW)  jammer  operating  in  the  10  GHz  ±  500  MHz  operating 
band  of  the  radar _ _ 


22  function  normally  in  the  presence  of  a  70  dBW  jammer 

operating  in  the  ISL  channel  freguencies _ _ 


23  provide  data  transmission  security  to  a  level  requiring  a 

minimum  time  of  72  hours  to  recover  the  data  by  unauthorized 
entities  with  a  projected  2003  technology  level _ 


24  employ  a  data  transmission  security  scheme  whereby  breaking  D,P 
the  security  once  must  not  lead  to  breaking  the  security 
method  in  less  time  on  subsequent  security  violation  attempts  _ 


25  route  messages  through  other  satellites  in  the  cluster  in  order  O 
to  reach  the  destination  satellite  _ _ 
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Table  2.  TS21  Requirements 


TS21  ISL  REQUIREMENTS 


The  ISL  system  shall:  


26  provide  message  routing  to  other  satellites  via  specific 
address  specification  / _ 


27  provide  message  routing  to  other  satellites  via  specific  route 
specification  _  . 


28  prioritize  requests  for  service  from  external  subsystems  and 
entities  _ _ 


29  preempt  current  link  operations  by  terminating  or  suspending 
current  operation  and  initiating  a  different  link  transmission 


30  have  each  satellite’s  ISL  subsystem  controllable  independent 
of  other  satellite  ISLs  _ _ _ 


31  have  each  satellite’s  ISL  subsystem  controllable  via  ground 
command  _ _ 


erform  a  satellite  group  self-test  automatical! 


33  perform  an  individual  satellite  ISL  subsystem  self-test 

automatically  _ _ 


341  perform  a  satellite  group  self-test  upon  ground  command 

initiation  _ __ 


35  perform  an  individual  satellite  ISL  subsystem  self-test  upon 
ground  command  initiation _ _  _ 


have  all  ISL  systems  with  equal  functional^ 


interface  to  the  payload  subsystem  _ . 


38  initiate  radar  data  link  transmissions  to  other  satellites  without 
ground  command  upon  impending  or  start  of  radar  operation 


have  access  to  payload  telemetry  data  _ 


inDut  data  and  commands  from  the  payload  subsystem 


output  data  and  commands  to  the  payload  subsystem 


42  transmit  satellite  position  information  while  transmitting  radar 
payload  data  _ 


43  be  able  to  receive  and  transmit  navigation  data  while  receiving 
and  transmitting  radar  payload  data _ _ 


44  receive  payload  data  while  transmitting  satellite  position  data 
to  other  satellites  _ _ _ 


45  employ  payload  command  and  data  reception  protection  to 
avoid  unauthorized  payload  access _ _ 


46  employ  payload  command  and  data  transmission  protection  to 
avoid  unauthorized  payload  access _ _ 


interface  to  the  Command  &  Data  Handling  (C&DH)  subsystem 


48  input  data  and  commands  from  the  Command  &  Data  Handling 
(C&DH)  subsystem  _ _ 


49  output  data  and  commands  to  the  Command  &  Data  Handling 
(C&DH)  subsystem  _  .  _ 


interface  to  the  navigation  subsystem _ 


51  initiate  operation  based  on  cluster  or  LAN  formation  flying 

control  without  ground  command _ _ 


allow  the  navigation  subsystem  to  initiate  ISL  operation _ 


have  access  to  other  subsystem  status  telemetry  data _ 


54  indicate  to  the  other  spacecraft  subsystems  that  there  is  some 
ISL  communications  activity _ _ 


not  interfere  with  payload  operations  _ 


not  interfere  with  spacecraft  operations  _ 


cause  no  collateral  damage  to  other  spacecraft  _ 


(continued) 
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Table  2.  TS21  Requirements  (continued) 


n 

TS21  ISL  REQUIREMENTS 

■ 

■ 

■ 

IE 

The  ISL  system  shall: 

a 

□ 

m 

AO 

SRC 

REF 

BY 

58 

comply  with  standard  electromagnetic 

interference/electromagnetic  compatibility  (EMI/EMC)  levels 
for  all  electronic  equipment  for  interference  with  other 
spacecraft  subsystems 

c 

M 

10 

H 

G99 

AFRL 

59 

abide  by  all  applicable  FCC  regulations  for  radio  frequency  and 
optical  energy  transmissions 

c 

M 

10 

HK 

M99 

p11,pa2 

MITL 

60 

output  energy  at  <  -210  dBW  within  the  10  GHz)  ±  500  MHz 
operatinq  band  of  the  radar  payload 

M 

10 

l,E,Q 

M99 

pi  3, pal 

AFRL 

61 

output  energy  at  <  30  dBW  outside  of  the  10  GHz  ±  500  MHz 
operatinq  band  of  the  radar  payload 

M 

10 

l,E,Q 

M99 

pi  3, pal 

AFRL 

in 

operate  at  altitudes  of  600  -  1000  km 

o 

M 

10 

l,Q 

M99 

p9,pa3 

BMil! 

operate  at  orbital  inclinations  of  50  -  90  degrees 

o 

M 

10 

l,Q 

M99 

p9,pa3 

Q3al 

m 

operate  at  orbital  satellite  ranqe  rates  of  <  1  m/s) 

El 

m 

KB 

l,Q 

M99 

p9,pa3 

a 

m 

have  a  mass  <  5  kq 

Q 

m 

1B1 

l,Q 

M99 

p10,pa4 

AFRLl 

have  a  stowed  (inside  launch  vehicle)  volume  <  0.3  m3 

B 

m 

IB 

l,Q 

M99 

p10,pa4 

UiiJ 

67 

fit  within  the  1 .2  m  diameter  by  0.45  m  high  stowed  volume 
envelope 

c 

M 

10 

Q 

TI99c 

AFRL 

68 

have  antenna  locations  less  than  2.8  m  away  from  the  center  of 
the  spacecraft 

c 

M 

10 

Q 

TI99c 

AFRL 

69 

not  be  in  the  hemispherical  volume  below  the  radar  payload 
antenna 

M 

10 

Q 

TI99c 

AFRL 

m 

have  a  power  consumption  of  <  20  W 

m 

KB 

l,Q 

M99 

pi  1fpa4 

m 

have  a  cost  of  <  $300K  when  produced  in  a  quantities  of  300 

iti 

KB 

l,Q 

M99 

pi  1,pa5 

AFRL] 

ID  Requirement  Identifier 

C  Category 

F  Functional 

D  Data 

P  Performance 

I  Interface 

O  Operational 

C  Constraint 

P  Priority 

M  Mandatory 

O  Optional 

F  Idea  for  further  development 

U  Uncertainty 

1 0  Shall  not  change 

1  Certain  to  change 

AO  AttributeOther 
I  Internal 

E  External 

C  Conflict 

Q  Quantitative 


SRC  Source 

M99  Operations  Concept  document 

C99  Documentation  used  in  defining  the 

Operations  Concept 

G99  Documentation  used  in  defining  the 

Operations  Concept 

TI99a-g  Technical  interchanges  between 

relevant  personnel 

DoD99.1  SBIR  satellite  LAN  contract 
solicitation 

REF  Reference 

p  Page 

pa  Paragraph 

BY  IdentifiedBy 

MITI  MiTech  Incorporated 

AFRL  AFRL  Personnel 


3.5  Operational  System  versus  Flight  Experiment  Requirements 

The  previous  table  contains  the  ISL  requirements  for  the  TS21  ISL  Operational  System  for  the  2008 
time  frame.  A  TS21  flight  experiment  is  planned  for  launch  in  the  2003  time  frame.  The  flight 
experiment  is  a  proof  of  concept  for  the  TS21  operational  mission.  Three  satellites  without  real¬ 
time  radar  data  processing  capability  comprise  the  flight  experiment  as  opposed  to  eight  satellites 
with  real-time  radar  data  processing  capability  for  the  operational  system.  As  a  result,  the  ISL 
requirements  for  the  flight  experiment  are  a  subset  of  the  ISL  requirements  for  the  operational 
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system  listed  in  Table  2:  ISL  Requirements.  At  this  point  in  time,  the  main  differences  in  ISL 
operational  versus  flight  experiment  requirements  are  that  no  payload  data  transmissions  are 
required,  and  the  timing  synchronization  and  position  determination  accuracy  are  relaxed  to  what  can 
be  achieved  in  time  for  the  flight  experiment. 

3.6  Requirements  Validation  and  Verification 

Requirements  validation  and  verification  are  a  critical  part  of  providing  an  ISL  satellite  subsystem 
that  performs  all  needed  operations  in  the  required  manner.  Requirements  validation  and  verification 
can  be  performed  through  satellite  program  personnel  review  of  the  requirements  specified  in  this 
document.  Requirements  categorized  with  priorities  of  “O”  (optional)  and  “F”  (idea  for  further 
development)  need  to  be  validated  and  verified  as  “M”  (mandatory)  requirements  or  deleted.  Any 
requirements  with  an  attribute  of  “C”  (conflict)  need  to  have  their  conflicts  with  other  requirements 
eliminated.  Requirement  conflicts  can  be  resolved  through  the  elimination  of  conflicting 
requirements  or  modification  of  the  requirements  to  remove  any  conflicts.  Program  office 
requirements  validation  and  verification  process  results  should  be  incorporated  into  a  revised, 
validated  and  verified  ISL  requirements  document. 
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4.0  ISL  ARCHITECTURE  DEFINITION 

The  ISL  architecture  validates  the  key  technology  to  be  employed,  assesses  the  feasibility  of  meeting 
the  ISL  requirements  and  defines  the  top  level  design  for  implementing  an  ISL. 

4.1  Purpose  / 

The  purpose  of  the  ISL  architecture  definition  is  to  identify  and  specify  an  implementation 
architecture  and  key  components  that  provide  for  a  future  detailed  design  and  implementation 
meeting  the  requirements  identified  earlier.  The  architecture  definition  also  serves  to  evaluate 
existing  and  emerging  wireless  technologies,  and  to  define  the  ISL  system  boundaries. 

4.2  Scope 

The  scope  of  the  ISL  architecture  definition  is  limited  to  defining  an  architecture  to  a  high  level. 
Hardware  and  software  components  are  only  identified  and  defined  to  the  level  necessary  to  lead  to 
an  ISL  detailed  design  capable  of  meeting  the  requirements. 

4.3  Approach 

Wireless  physical  transmission  and  media  access  methods,  hardware  and  software  applicable  to 
satellite  LANs  and  ISLs  were  analyzed.  Existing,  in  development  and  possible  future  development 
communication  technologies  and  components  were  evaluated  for  use  in  implementing  an  ISL  for  an 
operational  space  flight  planned  in  the  year  2003.  Heavy  emphasis  was  given  to  COTS  technology 
and  components  in  order  to  meet  the  short  development  schedule  of  the  TS21  program. 

Wireless  physical  transmission  and  media  access  methods  and  components  applicable  to 
satellite  LANs  and  ISLs  examined  and  evaluated  included  RF  and  optical  (laser)  versions  of  CDMA, 
time  division  multiple  access  (TDMA),  frequency  division  multiple  access  (FDMA)  and  for  optical 
transmission,  the  equivalent  of  FDMA  -  WDM.  Combinations  of  these  three  main  candidate 
technologies  are  also  possible.  Multi-carrier  CDMA,  or  orthogonal  frequency-division  multiplexing 
(OFDM)  and  wideband  CDMA  (W-CDMA)  methods  of  CDMA  are  promising  examples  of  additional 
wireless  optical  transmission  methods  examined  applicability  for  satellite  LAN  ISL  implementation 
[DGNS98,  HP97,  HWNC98], 

CDMA  or  spread  spectrum  technology  was  chosen  as  the  best  candidate  for  an  ISL 
architecture  and  implementation.  Spread-spectrum  is  a  means  of  transmission  in  which  the  signal 
occupies  a  bandwidth  in  excess  of  the  minimum  necessary  to  send  the  information.  The  bandwidth 
spread  is  accomplished  by  means  of  a  code  that  is  independent  of  the  data.  A  synchronized  reception 
with  the  code  at  the  receiver  is  used  for  despreading  and  subsequent  data  recovery.  Traditional  ways 
of  separating  signals  in  time  (i.e.,  TDMA),  or  in  frequency  (i.e.,  FDMA)  are  relatively  simple  ways  of 
making  sure  that  transmissions  are  orthogonal  and  non  interfering.  However,  in  CDMA,  different 
users  or  transmissions  occupy  the  same  bandwidth  at  the  same  time,  but  are  separated  from  each 
other  via  the  use  of  a  set  of  orthogonal  waveforms,  sequences,  or  codes.  There  are  two  main  types 
of  CDMA:  direct-sequence  spread  spectrum  (DSSS)  and  frequency-hopping  spread  spectrum  (FH-SS). 
Hybrids  of  combinations  of  the  two  CDMA  types  also  exist.  Of  the  different  types  of  CDMA,  direct 
sequence  CDMA  (DS-CDMA)  was  chosen  as  the  technology  of  choice  for  an  ISL.  DS-CDMA 
requires  a  simpler  transmitter  and  receiver  by  using  a  bit  pattern  code  to  provide  the  bandwidth 
spreading  rather  than  using  frequency  hopping  of  the  carrier  frequency  in  a  pseudo-random  fashion  to 
perform  the  bandwidth  spreading.  DS-CDMA  provides  all  characteristics  for  the  required  high  data 
rate,  low  bit  error  rates,  interference,  low  power,  security  and  Doppler  shift  requirements  of  satellite 
LANs  and  ISLs.  CDMA  technology  also  met  the  necessary  SBIR  requirement  of  a  technology  that 
can  be  commercialized.  A  high  data  rate  CDMA  transmission  system  is  of  immense  commercial 
interest.  Approximately  50  vendors  of  satellite  and  terrestrial  wireless  communications  link 
hardware,  including  Motorola,  Qualcomm,  Alcatel,  Marconi,  Sirius,  Hyundai  and  Hughes  were 
contacted.  The  emphasis  on  ISL  link  transmission  hardware  vendor  research  and  discussions  came 
down  to  CDMA  versus  FDMA  components.  Optical  technologies  and  components  were  not  available 
in  the  foreseeable  future  with  the  required  tracking  and  pointing,  LOS  obscuration  operations  and 
other  characteristics  (i.e.,  meeting  the  other  ISL  requirements).  Component  suppliers  for  Motorola, 


21 


AFRL- V  S-TR-2000- 1 070 


Raytheon,  Qualcomm  and  Globalstar  CDMA  products  such  as  Xilinx,  Texas  Instruments  and  Sirius 
appear  to  have  a  number  of  components  that  be  used  as  is  or  with  minor  modifications  for  a 
100  Mbps  ISL  in  space.  CDMA  encoding  and  decoding  application  specific  integrated  circuits 
(ASICs)  for  satellites  are  in  development  and  on  track  for  space  qualification  in  eight  months  time 
that  will  allow  ISL  link  rates  to  be  available  in  20  Mbps  increments. 

/ 

4.4  ISL  Antenna  Placement 

ISL  antenna  placement  will  make  for  some  shadowing,  areas  where  ISL  signal  transmissions  will  be 
blocked  by  the  satellite  structure.  If  satellites  are  placed  in  relation  to  one  another  where  the  ISL  RF 
radiation  LOS  is  blocked  from  one  satellite  to  another  satellite  (from  an  ISL  transmit  antenna  to  an 
ISL  receive  antenna),  the  ISL  could  cease  to  function  due  to  insufficient  signal  strength  at  the 
receiver.  Using  the  formulas  and  drawing  in  Figures  5  and  6,  some  noteworthy  calculations  can  be 
made. 

Given  ISL  antenna  placement: 

2  cm  high  (approx.  1  cm  circumference)  isotropic  ISL  antenna,  operating  at  about  1  GHz, 
placed  at  the  top  of  the  TS21  satellite,  communicating  with  another  TS21  satellite  10  m 
below  the  first  satellite. 

Results: 

23.6  dB  loss  of  ISL  transmit  signal  strength  from  the  satellite  on  top  to  the  satellite  on  the 
bottom  just  from  the  shadowing  caused  by  the  structure  of  the  satellite  above  blocking  the 
signal  to  the  satellite  below.  This  does  not  include  radiation  free  space  losses. 

Given  ISL  antenna  placement: 

2  cm  high  ISL  antenna,  operating  at  about  1  GHz,  placed  5  cm  (2  inches)  from  the  outer  edge 
of  the  radar  panel  on  top  of  the  radar  panel,  communicating  with  another  TS21  satellite 
10  m  below  the  first  satellite. 

Results: 

13  dB  loss  of  ISL  transmit  signal  strength  from  the  satellite  on  top  to  the  satellite  on  the 
bottom  just  from  the  shadowing  caused  by  the  structure  of  the  satellite  above  blocking  the 
signal  to  the  satellite  below.  This  does  not  include  radiation  free  space  losses. 

Lte(v)=-2  Olog^L 

,  ..ft,  |2(<V+<*2’)_„  I  2«W 

y  yAfo’+dj’) 


Figure  5.  Knife  Edge  Signal  Loss  (L|<e)  Calculation  for  ISL  Antenna  Shadowing  [S99] 
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Figure  6.  Shadowing  Caused  ISL  Signal  Loss  vs.  Distance  in  Shadow  Area  (v)  [S99] 

What  these  calculations  communicate  is  that  ISL  antenna  placement  makes  a  significant  difference 
in  the  amount  of  energy  received  at  the  ISL  antenna  of  another  satellite  when  shadowing  occurs  from 
the  structure  of  either  the  transmitting  or  receiving  satellite  obstructing  the  RF  path  between  ISL 
transmit  and  receive  antennas.  Operational  restrictions,  such  as  not  placing  satellites  within  ISL 
transmission  shadow  areas,  need  to  be  traded  off  against  ISL  antenna  placement  options. 

4.5  ISL  Architecture/High  Level  Design 

Figure  7  illustrates  MiTech’s  high  level  ISL  design  that  performs  all  functions,  100  Mbps  payload 
data  transmission,  3  mm  distance  calculations  and  20  ps  timing  references,  with  ranging  and  timing 
derived  from  the  received  CDMA  transmissions. 

Data  from  the  satellite  payload  or  other  subsystems  is  made  available  to  the  ISL  processor  for 
transmission  through  the  ISL  to  other  satellites.  Payload  data  or  other  subsystem  data  received  via 
the  ISL  is  also  taken  in  and  made  available  to  the  ISL  processor  for  routing  to  the  appropriate 
satellite  subsystem.  Data  is  transmitted  using  64-Quadrature  Amplitude  Modulation  Differential 
Quadrature  Phase  Shift  Keying  (64-QAM-DQPSK)  in  order  to  conserve  bandwidth  and  in  order  to 
provide  rapid  enough  phase  changes  for  picosecond  timing  and  millimeter  ranging  calculations.  A 
Walsh  64-bit  spreading  code  is  used  as  the  CDMA  code.  The  other  components  for  transmitting  are 
fairly  standard.  The  receiver  contains  the  same  components  in  reverse  order.  This  design  should 
yield  an  RF  system  that  can  operate  at  low  GHz,  near  1  to  5.7  GHz,  with  a  bandwidth  of  1.6  times 
that  of  the  data  rate.  If  the  data  rate  were  100  Mbps,  then  the  bandwidth  required  would  be 
160  MHz.  Operating  at  1  -  5.7  GHz  makes  possible  the  use  of  COTS  analog  RF  antennas,  amplifiers, 
modulators,  etc.  At  a  160  MHz  bandwidth,  COTS  analog-to-digital  (A/D)  and  digital-to-analog  (D/A) 
converters  can  also  be  utilized.  The  extensive  use  of  COTS  components  greatly  reduces  the  costs  and 
risks  of  the  ISL  system. 

Two  other  important  details  are  the  use  of  a  high  frequency  pilot  tone  for  synchronization  of 
the  receiver  and  transmitter,  as  well  as  for  extracting  3  mm  distance  calculations  and  20  ps  timing 
references  from  the  received  pilot  tone  phase  [CDMA  1-7].  The  pilot  tone  may  have  to  be 
modulated  by  a  bit  pattern  long  enough  for  phase  differentiation  to  the  20  ps  level.  The  concept  is 
to  use  a  high  frequency  pilot  tone  synchronization  signal,  with  a  wavelength  of  twice  that  of  the 
required  distance  measurement  requirement.  A  frequency  with  a  wavelength  of  twice  the  desired 
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ranging/distance  measurement  is  all  that  is  required  since  measurement  accuracy  is  possible  to  within 
1/2  that  of  the  smallest  measurement  unit.  The  principle  is  the  same  as  using  a  ruler  with  1/4  inch  as 
the  smallest  unit  of  measure.  With  such  a  ruler  one  can  measure  to  within  1/8  of  an  inch,  or  within 
1/2  of  the  smallest  unit  of  measure.  Using  1/2  of  the  measurement  of  the  50  GHz  wavelength  yields 
a  3  mm  distance.  For  example,  a  50  GHz  tone  has  a  wavelength  of  6  mm.  Half  of  the  wavelength  of 
a  50  GHz  tone  yields  a  3  mm  position  reference  point,  relative  to  the  transmitter  (to  the  other 
satellite).  Detecting  the  wavelength  position  (6  mm  length)  of  the  received  pilot  tone  and  the  phase 
of  the  received  pilot  tone,  and  comparing  these  two  measurements  with  the  phase  of  the  incoming 
64-QAM-DQPSK  data  and  reference  pilot  tone  phase  and  wavelength  position,  should  yield  a  3  mm 
distance  to  transmitter  calculation.  The  CDMA  Phase  and  Pilot  Tone  Logic  in  Figure  5  makes  the 
wavelength  pilot  tone  and  phase  measurements  in  order  to  output  a  3  mm  relative  distance  to 
transmitter  and  a  20  ps  (using  the  50  GHz  half  wavelength)  timing  reference.  A  50  GHz  tone  has  a 
wavelength  time  of  1/f,  or  20  ps.  Using  the  measurement  principle  of  measuring  within  1/2  of  the 
smallest  unit  of  measure,  a  20  ps  timing  reference  is  possible. 


Figure  7.  Integrated  CDMA  ISL  System  with  Picosecond  Timing  and  Millimeter  Ranging 

The  advantage  of  the  approach  illustrated  in  Figure  7  is  that  the  entire  position  determination 
functionality  is  integrated  into  one  package,  yielding  the  most  power,  volume  and  weight  efficient 
implementation  of  the  required  ISL,  ranging  and  payload  timing  functionality. 

A  standard  (COTS)  differential  GPS  receiver  and  antenna  are  used  to  provide  absolute  satellite 
position  determination  to  within  2  cm.  The  output  of  the  CDMA  Phase  and  Pilot  Tone  Logic 
provides  relative  position  accuracy  to  within  3  mm  for  the  distance  from  satellite  to  satellite. 
Combining  the  ISL  3  mm  relative  position  with  the  GPS  20  mm  absolute  position  can  yield  the 
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required  absolute  satellite  cluster  position  accuracy  of  3  mm.  The  ISL  3  mm  relative  distance 
information  is  used  to  narrow  the  differential  GPS  derived  position  from  20  mm  (2  cm)  to  3  mm. 

No  GPS  data  needs  to  be  sent  between  satellites  in  order  to  derive  the  relative  position  of  each 
satellite  to  within  3  mm. 

The  transmission  of  the  payload  data,  subsystem  command  and  status  data,  or  formation 
flying  data  via  the  CDMA  ISL  link  is  sufficient  to  provide  3  mm  position  and  20  ps  timing  outputs. 
This  ISL  system  is  fully  contained  and  requires  no  additional  inputs  in  order  to  provide  3  mm  satellite 
position  and  20  ps  payload  timing. 

Figure  8  is  essentially  the  same  CDMA  receiver  and  transmitter,  and  associated  3  mm 
distance  calculation  and  10  ps  timing  reference  derivation  logic  as  in  Figure  7.  The  major  difference 
in  the  ISL  system  of  Figure  8  are  that  the  time  reference  source  is  not  a  GPS  receiver,  but  rather  a 
high  resolution,  highly  stable  rubidium  oscillator  from  the  payload  subsystem,  and  that  the  GPS 
receiver  and  GPS  position  determination  functions  are  located  in  a  separate  GPS  subsystem. 

Even  in  this  case  however,  no  separate  GPS  data  needs  to  be  sent  from  satellite  to  satellite  in 
order  to  determine  satellite  position  to  within  3  mm  or  in  order  to  provide  20  ps  payload  timing  and 
synchronization  signals.  A  standard  differential  GPS  subsystem  receiver  could  be  used  with  the 
configuration  in  Figure  8,  where  the  ISL  processor  integrates  the  GPS  2  cm  position  data  with  the 
CDMA  ISL  data  to  output  3  mm  position  and  20  ps  timing  and  synchronization  signals  and  data. 


Figure  8.  Separate  CDMA  ISL  and  GPS  Systems  with  ISL  Picosecond  Timing  and  Millimeter  Ranging 

Augmentation  of  GPS  Position  Calculation 
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The  advantage  the  approach  illustrated  in  Figure  8  is  that  the  GPS  functionality  is  separated  from  the 
ISL  functionality.  The  two  functions,  GPS  and  ISL,  can  therefore  be  separated  into  two  subsystems 
with  independent  developments,  testing  and  integration  schedules  and  locations. 

Design  and  implementation  of  an  ISL  prototype  were  not  part  of  this  SBIR  Phase  I  effort. 
However,  based  on  the  previous  requirements,  architecture  definition  and  component  availability 
(both  near  term  and  in  time  for  a  2008  satellite  launch),  some  top  level  design  information  can  be 
determined.  A  flight  ISL  system  is  envisioned  to  look  like  the  prototype  implementation  depicted  in 
Figure  9. 
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Figure  9.  Prototype  ISL  Design 


Field  Programmable  Gate  Arrays  (FPGAs),  such  as  the  Virtex-E  series  by  Xilinx  Inc.,  and  the 
CommsDAC™  Product  Family  of  A/D  and  D/A  converters  by  Texas  Instruments  Inc.  can  provide 
close  to  100%  of  all  required  functionality  and  electrical  requirements.  The  XCV2000E  FPGA  device 
by  Xilinx  contains  more  than  enough  logic  gates  (>  2  million  system  gates)  and  high  enough  clocking 
speed  to  implement  as  much  as  possible  of  the  CDMA  receiver  and  transmitter  in  the  digital  rather 
than  analog  domain.  Texas  Instruments  D/As  and  A/Ds  such  as  the  THS5661A,  when  concatenated 
together  and  used  in  parallel  operation,  can  provide  the  necessary  domain  conversions  for  a 
100  Mbps  data  rate  DS-CDMA  signal  transmission  and  reception.  20  Mbps  CDMA  chips  by  Sirius 
Communications  could  also  be  used  in  the  implementation  if  incremental  data  rate  transmission  were 
an  important  feature  of  the  ISL.  Low  spreading  rates  through  high  symbol  encoding  (e.g.,  64-bit 
QAM-DQPSK)  are  important  in  maintaining  a  transmission  rate  that  is  a  reasonable  multiple  of  the 
of  the  data  rate  (e.g.,  1.6  -  as  in  the  proposed  architectures  of  Figures  7  and  8).  A  CDMA  low  power 
design  and  implementation  example  that  is  very  similar  and  applicable  to  an  ISL  implementation  is 
presented  in  [SB99]. 
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5.0  IDENTIFY  AND  ANALYZE  WIRELESS  SOFTWARE/HARDWARE 
COMMUNICATION  PROTOCOLS 

The  communication  protocols  above  the  physical  layer  (including  data  link,  network,  transport  and 
application)  for  the  ISLs  are  identified  and  analyzed.  Previous  tasks  specified  the  physical  layer  as  a 
function  of  the  available  COTS  CDMA  RF  transmission  components.  The  physical  layer  DS-CDMA 
or  DSSS,  along  with  this  task’s  data  link  layer  protocol  definition  and  specification,  complete  the 
entire  communications  architecture  necessary  for  ISL  communication.  The  Open  Systems 
Interconnect  (OSI)  Reference  Model  (OSI-RM)  representation  of  the  entire  communications  model 
is  depicted  in  Figure  10. 


Figure  10.  Open  Systems  Interconnection  Reference  Model  for  Communication 

5.1  Purpose 

The  purpose  of  this  task  is  to  identify  and  specify  the  entire  communications  protocol  architecture 
for  the  ISL  subsystem. 

5.2  Scope 

Physical,  data  link  layer  and  some  form  of  application  layer  protocol  functionality  is  required  for 
any  type  of  ISL  communication.  Due  to  the  COTS  nature  of  the  ISL  design,  the  physical  layer 
protocol  functionality  will  be  determined  by  the  RF  COTS  components  selected  for  the  ISL 
prototype  and  flight  unit  implementations.  The  hardware  components  selected  for  implementing  a 
CDMA  based  RF  ISL  will  include  the  physical  layer  and  media  access  control  communications 
protocol  functions.  The  scope  of  identifying  and  analyzing  ISL  protocols  is  therefore  limited  to 
those  protocols  above  the  physical  layer  and  the  media  access  control  portion  of  the  data  link  layer. 


5.3  Approach 

The  absolute  minimum  communications  protocol  architecture  or  protocol  stack  includes  the  physical 
layer,  data  link  layer  functionality  and  some  form  of  application  layer  data  exchange  syntax  and 
format  specification.  The  data  exchange  syntax  and  format  specification  can  be  derived  from  the 
data  link  layer  protocol  specification  if  the  data  link  layer  specification  includes  data  syntax  and 
format  specifications.  A  communications  architecture  composed  of  a  Physical  and  Data  Link  Layer 
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protocol  stack  is  therefore  the  minimum  and  hence  highest  performance  communications  protocol 
architecture  available.  All  protocol  functionality  above  the  data  link  layer  (network,  transport, 
session  and  presentation  layer)  are  optional  and  deemed  as  unnecessary  overhead  for  ISL  operation. 
Since  the  physical  layer  is  dictated  by  the  CDMA  components,  only  the  Data  Link  Protocol  (DLP) 
needs  to  be  specified. 

The  data  link  layer  and  application  layer  protocol  candidates  examined  were  IEEE, 
International  Standards  Organization  (ISO),  Instrument  Society  of  America  (ISA),  Internet 
Engineering  Task  Force  (IETF)  existing  and  proposed  protocols  and  standards  (i.e.,  Request  for 
Comments  -  RFCs)  and  custom  implementations  of  data  link  and  application  layer  protocols. 
Protocol  candidates  for  consideration  in  this  task  included  such  protocol  standards  as  HDLC,  ATM, 
IP,  TCP,  UDP,  XTP,  application  layer  protocols  such  as  the  Manufacturing  Message  Specification 
(MMS  -  ISO  9506)  and  the  Simple  Network  Management  Protocol  (SNMP  -  RFC  1157),  and  a 
complete  protocol  stack,  ISA’s  SP-50.  Modifications  to  these  existing  protocols  and  completely 
new  protocols  were  also  considered. 

5.4  Protocol  Requirements 

In  order  to  arrive  at  which  protocol  or  protocols  are  best  for  an  ISL  implementation,  communication 
protocol  requirements  are  defined.  Once  requirements  are  defined,  matching  candidates  to 
requirements  reveals  the  optimum  selections. 

Utilization  of  ISLs  for  a  TS21  space  based,  sparse  synthetic  aperture  radar  requires  three  top 
level  functions  of  the  ISLs:  a)  timing  reference  determination  and  synchronization,  b)  position  or 
range  determination  and  c)  transfer  of  1 00  Mbps  or  more  of  radar  data  between  the  satellites.  With 
estimated  timing  needs  to  the  20  ps  level  and  estimated  position  determination  to  the  3  mm  level, 
along  with  Mbps  data  transfer,  performance  is  the  dominant  criteria  for  identifying  and  specifying 
ISL  protocols  and  their  requirements. 

The  data  link  control  protocol  will  have  to  provide  the  needed  functionality  (establish  a 
reliable  bit  pipe  from  sender  to  receiver  to  include  data  syntax  and  format  specification)  and  will 
have  to  meet  five  top  level  requirements: 

1 .  Performance 

Minimize  the  protocol  overhead  in  terms  of  hardware,  processing  time  and  throughput  delay 

2.  COTS  Interoperability 

Interoperate  with  available  hardware  and  software 

3.  Quality  of  Service  (QoS)  functionality 

Provide  the  necessary  error  rate  and  data  (radar,  ranging  and  timing)  services 

4.  Interface 

Provide  a  flexible  and  high  performance  with  acceptable  cost,  weight,  volume  and  power 

characteristics 

5.  Manufacturing 

Provide  commercially  acceptable  cost,  weight,  volume,  power  and  interface  characteristics. 
5.4.1  Performance  Requirements 

The  performance  of  an  ISL  communications  protocol  stack  can  be  defined  in  a  number  of  ways.  In 
most  cases,  link  performance  is  defined  as  the  percentage  of  the  link  bandwidth  used  for  data 
transmission  for  a  given  error  rate  and  signal  to  noise  ratio.  Performance  can  also  be  defined  as  the 
percentage  of  the  link  bandwidth  used  for  data  transmission  for  a  given  QoS.  C2  applications  require 
higher  QoS  than  data  transmission  applications.  C2  QoS  requirements,  such  as  in  order  delivery  of 
error  free  command  and  position  data  packets,  typically  require  higher  forward  error  correction 
(FEC),  Automatic  Repeat  Request  (ARQ)  and  encoding  transmission  overhead  than  a  data 
transmission  which  can  tolerate  lost,  error  containing  and  out  of  order  data  packets.  Since  the 
physical  layer  performance  is  dictated  by  the  available  CDMA  components  and  therefore  addressed  in 
an  earlier  task,  only  the  DLP  performance  needs  to  be  specified. 

For  the  ISL-DLP  (ISLP),  performance  is  improved  significantly  over  existing  High-Level 
Data  Link  Control  (HDLC),  Space  Communications  Protocol  Standards  (SCPS),  Consultative 
Committee  on  Space  Data  Systems  (CCSDS)  and  proprietary  space  link  protocols  through  extension 
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of  DLP  functionality  to  include  performance  enhancing  QoS  functions.  The  main  performance 
enhancing  QoS  functions  are: 

1 .  Adaptive  header  and  data  compression  ratios  and  algorithms 

2 .  Selective  repeat  ARQ  (SR-ARQ)  with  multiple  buffers 

3.  Variety  of  adaptive  FEC  algorithms  selected  according  to  application  needs  and  link 

transmission  characteristics. 

The  additional  QoS  capabilities  of  the  ISLP  eliminate  the  need  for  additional  upper  layer  protocols 
through  the  use  of  the  additional  QoS  services.  The  elimination  of  upper  layer  protocols  provides 
another  large  performance  benefit.  The  upper  layer  protocol  implementation  can  affect  the  overall 
link  data  throughput  performance  more  than  all  the  QoS  and  other  performance  enhancing  features 
of  the  data  link  protocol.  In  fact,  the  implementation  of  protocols  used  above  the  data  link  protocol 
affect  the  performance  of  the  link  more  than  all  the  data  link  protocol  factors  combined. 

QoS  service  selection  and  implementation  can  greatly  affect  data  link  performance.  A  good 
hardware  implementation  can  assure  that  additional  QoS  services  and  their  execution  do  not  limit 
data  throughput  to  something  less  than  the  link  transmission  capacity. 

Performance  analyses  and  data  is  presented  in  Section  5.9:  Performance.  Sections  5.9. 1.6 
and  5.9. 1.7  with  their  real  world  data  measurements  provide  the  basis  for  the  recommendation  that 
the  ISL  use  only  a  data  link  layer  protocol.  The  use  of  additional  protocol  functionality  above  the 
data  link  layer  via  a  separate  protocol  is  deemed  to  be  extremely  risky.  It  seems  unlikely  that  an  ISL 
implementation  with  an  upper  layer  protocol  can  achieve  100  Mbps  data  transfer  rates,  20  ps  timing 
and  3  mm  estimated  position  determination  performance. 

5.4.2  COTS  Interoperability 

COTS  interoperability  is  defined  as  the  ISL  DLP’s  ability  to  work  with  the  hardware  and  software 
available  to  implement  the  ISL  link.  Since  the  physical  layer  interoperability  is  dictated  by  the 
available  CDMA  technology,  discussed  in  a  previous  task,  only  the  DLP  interoperability  needs  to  be 
specified. 

The  new  service  extensions  to  HDLC  are  defined  in  such  a  way  as  to  be  interoperable  with 
existing  HDLC  compliant  implementations  and  with  the  HDLC  standard.  New  services  are  added 
using  the  existing  procedures  and  frame  structure  of  the  HDLC  standard.  All  of  the  above  service 
parameters  are  defined  and  selected  using  the  existing  content  and  format  of  the  HDLC  Information 
Transfer  Frame  (I-frame),  Unnumbered  Command  Control  Frame  (U-frame),  Supervisory  Frame 
(S-frame)  and  Exchange  Information  Frame  (XID-frame).  The  U-frame  is  used  to  convey  that  the 
ISLP  version  of  HDLC  is  being  used  with  the  optional  QoS  extensions.  The  QoS  function  selection 
and  implementation  are  conveyed  in  the  beginning  of  the  I-frame  information  or  user  data  field. 

The  XID-frame  is  used  to  confirm  QoS  selections  for  available  resources  and  to  set  existing  HDLC 
parameters,  such  as  maximum  information  field  length,  window  size  and  timers,  to  match  the  selected 
QoS  options. 

Together,  the  existing  U,  I,  S  and  XID  frames  implement  an  extended  ISLP  that  is 
interoperable  with  HDLC,  provides  additional  services  and  additional  performance.  Interoperability 
with  HDLC  compliant  protocols  is  felt  to  be  a  necessity  for  commercial  applications  of  the  new 
ISLP. 

Interoperability  with  the  SCPS  and  Internet  TCP/IP  and  UDP/IP  protocols  is  assured  through 
the  concept  of  encapsulation  and  compliance  with  the  HDLC  data  link  layer  service  specification. 
The  entire  Internet  protocols  can  be  encapsulated  inside  the  ISLP  user  data  field,  preserving 
IP/TCP/UDP  functionality  and  interoperability.  If  the  network  and  transport  protocol 
(IP/TCP/UDP)  functionality  is  desired  for  some  commercial  application,  these  protocols  can  be  used 
on  top  of  the  ISLP  without  modification. 

Interoperability  with  the  CCSDS  protocols  and  existing  space  link  systems  is  achieved 
through  the  use  of  the  existing  eight  CCSDS  protocol  services:  Internet,  Path,  Encapsulation, 
Multiplexing,  Bitstream,  Virtual  Channel  Access  (VCA),  Insert,  and  Virtual  Channel  Data  Unit.  With 
the  use  of  the  existing  CCSDS  services,  a  careful  selection  of  the  combination  of  ISLP  functionality 
(especially  the  new,  extended  services)  and  CCSDS  services  is  required  in  order  to  achieve  reasonable 
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performance.  Using  the  new  ISLP  in  place  of  the  equivalent,  duplicated  functions  within  CCSDS 
protocols  would  require  modification  of  the  CCSDS  VCA  and  Virtual  Channel  Link  Control  (VCLC) 
data  link  protocols.  Interoperability  with  CCSDS  presently  requires  the  overhead  of  CCSDS 
protocols.  Proposing  to  the  CCSDS  committee  to  modify  their  VCA  and  VCLC  protocols  to  provide 
the  functionality  of  the  new  ISLP  is  an  option  that  should  be  pursued  if  higher  performance  and 
CCSDS  interoperability  is  desired. 

With  the  use  of  an  extended  HDLC  as  the  ISLP,  interfaces  can  follow  the  ISO  standards  for 
interfacing  between  the  data  link  and  the  physical  protocol  layers  [ISO  10022],  and  between  the  data 
link  and  network  protocol  layers  [IS08886]  of  the  ISO  OSI  reference  model  [IS07498].  The 
existing  service  interfaces  support  the  new  data  link  services.  This  may  be  a  significant  advantage 
for  interfacing  the  ISL  subsystem  to  other  TS21  satellite  subsystems.  HDLC  software  and  hardware 
implementation  and  testing  support  is  readily  available  for  a  Real-Time  Operating  System  (RTOS) 
and  an  Operating  System  Environment  (OSE)  link  manager,  both  of  which  are  likely  to  be  employed 
by  other  TS2 1  subsystems  interfacing  to  the  ISL  subsystem. 

5.4.3  QoS  Functionality 

QoS  functionality  is  defined  as  the  set  of  communication  link  performance  and  functional  parameters 
required  to  provide  the  necessary  error  rate  and  data  (radar,  ranging  and  timing)  services.  The 
communication  parameters  result  from  the  negotiation  of:  a)  services  offered  by  the  link  protocols 
to:  users,  applications  or  systems  and  b)  services  requested  from  the  link  protocols  by:  users, 
applications  or  systems.  The  transmission  link  parameters  of  the  protocol  services  define  the  QoS 
functionality.  QoS  functionality  is  therefore  implemented  through  protocol  services.  Modifications 
or  additions  to  existing  protocol  services  may  be  made  to  a  communications  protocol  to  provide  the 
QoS  required  by  the  communicating  entities. 

QoS  services  specify  communication  link  properties  such  as  performance  (throughput  and 
time  delays),  reliability  and  security.  An  application’s  QoS  needs  and  requests,  such  as  the  preferred 
degradation  path  (e.g.,  higher  data  rate  with  higher  error  rate  vs.  lower  data  rate  and  lower  error  rate), 
are  translated  into  link  QoS  services  such  as  FEC  algorithm  and  message  transfer  unit  (MTU)  size 
selection,  which  are  protocol  services.  The  QoS  parameters  and  specifications  may  change  during 
the  data  transmission.  Since  the  physical  layer  communications  functionality  is  dictated  by  the 
available  CDMA  components  and  therefore  defined  in  an  earlier  task,  only  the  DLP  functionality  is 
specified. 

In  the  case  of  the  ISLP,  where  the  FEC,  compression  and  all  QoS  services  can  be  modified, 
turned  off  or  on  at  the  request  of  a  link  user  or  link  performance  optimization  program,  there  is  no 
QoS  service  which  does  not  affect  link  performance.  Table  3  summarizes  the  QoS  functions 
proposed  and  defined  for  the  ISLP.  Any  or  all  of  the  data  link  protocol  functions  in  Table  3  can  be 
selected  for  the  ISLP.  In  the  case  where  a  function  is  not  desired  or  performed  outside  of  the  ISLP 
(e.g.,  compression/decompression,  encryption/decryption),  the  QoS  function  is  simply  not  used.  Any 
overhead  associated  with  unused  QoS  ISLP  functions  is  not  incurred  by  ISLP  processing. 

The  TS21  ISL  will  most  likely  utilize  a  maximum  of  three  of  the  21  defined  QoS  services: 
FEC,  ARQ  and  possibly  compression.  Implementations  of  ISLP  QoS  functions  are  possible  that  do 
not  restrict  the  performance  of  the  link  in  terms  of  reducing  the  data  throughput  to  less  than  that 
needed  for  real-time  radar  data  transmissions.  It  is  not  necessary  to  restrict  QoS  services  to 
rudimentary  offerings. 

5.4.4  Interface 

An  ISL  communications  protocol  interface  is  the  definition  of  the  physical  (e.g.,  electrical  and 
optical)  signal  encoding,  data  syntax,  format  and  protocol  services  (including  invocation  and 
termination). 

An  ISL  communications  protocol  interface  exists  between:  a)  ISL  subsystems  on  different 
TS21  satellites,  b)  the  ISL  subsystem  and  non  TS21  satellite  constellation  communication  sites  such  a 
ground  station  and  c)  the  ISL  subsystem  and  other  subsystems  onboard  the  same  satellite.  Potential 
TS21  ISL  requirements  include  transmitting  radar  data  to  the  ground  and  receiving  commands, 
uploads,  etc.  from  the  ground.  An  ISL  to  ground  interface  is  therefore  a  likely  ISLP  interface. 
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The  requirements  for  the  protocol  interface  are  to  provide  a  flexible  and  high  performance  with 
acceptable  cost,  weight,  volume  and  power  characteristics.  There  are  two  main  categories  of  TS21 
ISL  interfaces:  1)  transmission  and  2)  physical  subsystem. 


Table  3.  The  Existing  HDLC  Protocol  is  extended  to  include  21  QoS  Functions 


|  ISLP  QoS  FUNCTIONALITY  ) 

QoS  Function 

Range 

Throuqhput  or  Bandwidth 

1 .  Data  packet  (MTU)  size 

few  bytes  to  Megabytes 

2.  Number  of  bits  per  second 

User  selectable  to  >  100  Mbps 

3.  Rate  (for  consecutive  packets) 

User  selectable 

4.  Seqmented  delivery 

Yes  or  No 

5.  Flow  control  and  congestion  control 

6.  Compression 

none  to  more  than  100  to  1 

Time 

7.  Delay  limits 

milliseconds  to  hours 

8.  Response  time 

milliseconds  to  minutes 

9.  Jitter 

milliseconds  to  seconds 

10.  Interstream  synchronization 

none  to  milliseconds 

none  to  prioritizing  link  queues 

Reliability 

12.  Data  corruption  threshold 

many  errors  OK  to  no  errors  allowed 

13.  Data  loss  threshold 

packet  loss  OK  to  no  bit  loss  required 

14.  Replication  of  data 

acceptable  or  not  tolerated 

15.  Data  delivery  order 

no  order  to  specific  order 

1 6.  Group  delivery 

no  to  all  in  group  must  confirm 

17.  Forward  error  correction  (FEC) 

none  to  50%  of  total  #  of  bits/second 

18.  Automatic  repeat  request  (ARQ) 

Go-back-N  or  selective  repeat 

Security 

■  Kii;W iM WU?  Hi  U 

none  to  lenqthy  access  codes 

none  to  256  bit  keys 

1  21.  Data  unit  manipulation 

none  to  byte  by  byte 

5.4.4. 1  Transmission 

The  ISL  communications  transmission  interface  is  the  connection  provided  by  the  wireless 
transmission  of  CDMA  encoded  RF  signals  and  includes  the  physical  layer,  data  link  layer  and  any 
other  additional  upper  layer  protocol  interfaces.  The  interface  between  ISL  subsystems  on  different 
TS21  satellites  and  the  ISL  subsystem  and  a  ground  station  are  transmission  type  interfaces.  These 
interfaces  include  the  physical,  data  link  and  any  upper  layer  protocol  interfaces.  The  physical  layer 
interface  is  defined  by  the  chosen  CDMA  RF  transmission  technology  components  and  is  defined  in 
the  previous  task:  ISL  Architecture  Definition. 

The  ISLP  interface  is  the  standard  set  of  HDLC  protocol  services  and  their  interfaces.  All 
HDLC  extensions,  the  set  of  TS21  ISL  selectable  QoS  function  extensions  to  HDLC,  use  the  standard 
HDLC  services,  procedures  and  interfaces  as  defined  in  ISO  13239,  4335,  3309,  8886  and  10171. 

The  interface  for  all  possible  HDLC  extensions  is  depicted  in  a  following  section.  No  further 
protocol  interfaces  are  required  if  the  recommendation  to  use  no  additional  protocols  is  followed. 

Flexibility  of  the  protocol  interface  is  maximized  at  the  physical  layer  through  the  use  of 
CDMA  and  the  CDMA  inherent  characteristics  of  pseudo-noise  codes  (for  adding  new  links  to  the 
system)  and  RF  spectrum  sharing,  and  through  the  use  of  a  QoS  extension  mechanism  applied  to  the 
HDLC  protocol,  defining  an  international  standard  HDLC  protocol  interoperable  ISLP.  With  the 
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QoS  extensions,  the  ISLP  provides  a  very  flexible  interface  in  that  many  aspects  of  the  interface  can 
be  negotiated  on  a  communication  by  communication  basis.  All  the  aspects  of  the  communications 
protocol  interface  listed  in  Table  3  can  be  altered  and  set  to  optimize  the  specific  communication 
interface. 

The  impact  of  the  DLP  on  interface  performance  has  already  been  discussed  under  the 
previous  section.  The  selection  of  QoS  options  such  as  FEC  algorithm,  ARQ  mechanism  and 
compression  can  greatly  enhance  the  performance  of  an  ISL  communications  protocol  interface 
without  sacrificing  the  advantages  of  interoperability  and  implementation  of  an  international 
standard  DLP. 

Cost,  volume,  weight  and  power  characteristics  of  an  ISLP  based  on  an  extended  HDLC 
protocol  have  been  discussed  in  the  previous  section  on  manufacturing.  A  communications  protocol 
interface  using  only  a  data  link  layer  protocol  and  using  an  existing  standard  (i.e.,  HDLC)  as  the  basis 
for  the  DLP,  provides  the  lowest  cost,  volume,  weight  and  power  combination  while  providing  the 
necessary  performance. 

If  additional  upper  layer  protocols  are  used,  the  interfaces  between  HDLC  (or  whatever  is 
used  as  the  data  link  layer  protocol  for  the  ISLP)  and  any  additional  protocols  must  be  specified  and 
implemented. 

5. 4. 4. 2  Physical  Subsystem 

The  ISL  communications  physical  subsystem  interface  is  the  connection  between  the  ISL  subsystem 
and  other  subsystems  onboard  the  TS21  satellite.  This  satellite  subsystem  interface  is  usually  a 
physical  connection  such  as  a  electrical  or  optical  wires,  cables,  busses  or  LANs. 

This  interface  is  a  communications  protocol  interface  in  the  sense  that  the  data  syntax, 
format  and  transmission  procedures  must  be  specified.  The  physical,  and  possibly  the  data  link  and 
network  layer  protocols,  are  defined  by  the  selected  physical  connection,  such  as  an  IEEE  1553  or 
IEEE  1014  Versa  Module  Eurocard  (VME)  bus.  In  the  case  of  a  physical  connection  where  only  the 
physical  layer  protocol  is  specified,  for  example  RS-422.  the  data  link  layer  protocol  will  need  to  be 
defined.  In  the  extreme  case  where  only  wires  or  optical  fibers  are  used,  even  the  physical  layer 
protocol  will  need  to  be  specified.  Although  the  definition  of  this  interface  is  not  a  part  of  the 
internal  ISL  communications  and  hence  not  within  the  scope  of  this  task,  because  this  interface 
impacts  the  ISL  subsystem,  some  recommendations  are  provided. 

The  optimum  performance  from  an  ISL  standpoint  would  be  to  use  the  same  or  very  similar 
DLP  (i.e.,  HDLC)  for  the  internal  satellite  ISL  to  other  subsystem  interface  as  is  used  for  the  DLP 
within  the  ISL  subsystem,  for  communication  between  satellites.  This  would  reduce  ISL 
implementation  costs  (power,  volume,  weight  and  dollars)  by  not  having  to  design  and  implement 
additional  circuitry  for  an  additional  protocol.  Performance  would  also  be  maximized  by  utilizing  the 
fewest  number  of  protocols,  hence  eliminating  additional  processing  for  protocol  conversion  and 
implementation  functions.  For  a  payload  data  rate  of  100  Mbps,  a  physical  connection  with  a 
greater  than  100  Mbps  transmission  rate  should  be  selected.  This  would  eliminate  VME  and  1553 
busses  from  the  available  options. 

The  selection  of  physical  ISL  to  other  onboard  subsystem  interface  could  include  such  criteria 
as  available,  standard  COTS  components,  a  data  rate  of  >  100  Mbps,  a  packet  size  optimized  for 
radar  data  size  (e.g.,  eliminating  Asynchronous  Transfer  Mode  -  ATM  and  its  48  byte  packets),  and 
power,  volume  and  weight.  A  potential  candidate  meeting  all  criteria,  including  HDLC  support, 
might  be  the  Myrinet  LAN  technology  by  Myricom  Inc. 

5.4.5  Manufacturing 

Manufacturing  requirements  for  an  ISLP  or  any  other  layer  protocol  (e.g.,  network  -  IP,  transport  - 
TCP,  or  application  -  MMS)  center  on  four  requirements: 

1 .  Cost 

2.  Weight 

3 .  Volume 

4.  Power. 
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The  manufacturing  cost  requirement  is  composed  of  two  aspects,  initial  and  recurring  cost.  Initial 
engineering  costs  of  designing  the  first  unit  and  engineering  costs  incurred  as  a  result  of  design 
changes  from  the  first  production  unit  to  the  mass  production  are  not  included  in  manufacturing  cost. 
Initial  manufacturing  cost  is  the  amount  of  resources  required  to  manufacture  the  first  production 
unit.  Recurring  manufacturing  cost  is  defined  as  the  resources  required  to  mass  produce  units. 

Facilities  and  tooling  costs  (clean  rooms,  sub-micron  fabrication  and  test  equipment),  raw  materials, 
component  costs  and  their  availability  are  the  main  factors  determining  manufacturing  costs. 

Physical  layer  manufacturing  is  dictated  by  the  available  CDMA  components  and  is  addressed  in  an 
earlier  task.  Physical  and  DLP  manufacturing  are  closely  linked  in  that  DLP  manufacturing  consists 
of  implementing  the  DLP  in  some  of  the  same  hardware  (e.g.,  FPGAs)  that  some  of  the  physical 
layer  (CDMA,  etc.)  functionality  resides. 

In  the  case  of  the  ISLP,  existing  facilities  and  tooling  can  be  used  to  produce  the  hardware 
based  ISLP  units.  There  are  no  special  raw  materials  required  to  implement  the  ISLP  with  the  desired 
performance,  weight,  volume  and  power  characteristics.  Gallium  Arsenide  or  other  exotic  materials 
and  their  associated  increased  manufacturing  costs,  low  yield  and  availability  delays  can  be  avoided. 
Complementary  Metal  Oxide  Semiconductor  (CMOS)  technology  and  its  associated  low 
manufacturing  and  raw  materials  costs  can  be  utilized  for  ISLP  manufacturing.  Current  manufacturing 
facilities  and  very  large  scale  integration  (VLSI)  components  can  be  utilized  to  manufacture  a  ISLP 
printed  circuit  boards  or  interface  cards.  Despite  the  need  for  parallel  processing,  high  speed 
component  interconnections  and  potentially  Gigabytes  of  memory  for  implementation  of  an  ISLP 
and  associated  QoS  service  functions  at  megabit  per  second  rates,  existing  VLSI  integrated  circuits 
such  as  FPGAs  can  be  used  to  produce  prototype  and  mass  produced  units. 

Custom  VLSI  implementation  of  the  entire  ISLP  has  a  number  of  satellite  resource  utilization 
advantages  in  that  the  amount  of  required  power,  weight  and  volume  for  an  ISL  can  be  reduced.  If 
custom  VLSI  implementation  is  the  chosen  manufacturing  method,  the  initial  cost  of  the  first  unit 
escalates  substantially.  Recurring  costs,  however,  could  possibly  be  decreased  through  the  lower 
component  count  of  custom  VLSI  manufacturing.  Figure  9  is  a  representative  FPGA  based  ISL 
prototype  implementation  which  includes  the  entire  ISL  communications  protocol  stack,  physical 
layer  and  all  DLP  processing  (which  is  the  transmission  interface),  and  subsystem  interface. 

Weigfit,  volume  and  power  manufacturing  DLP  requirements  dictate  a  final  product  that  can  be 
used  on  a  TS21  satellite  where  weight,  volume  and  power  are  at  apremiun.  From  a  TS21  satellite  point 
of  view,  the  less  weight,  volume  and  power,  the  better.  From  a  manufacturing  point  of  view,  the  less 
wei^it,  volume  and  power,  the  more  difficult  and  expensive  manufacturing  can  become.  In  the  case  of 
ISLP  product  manufacturing,  a  FPGA  or  custom  VLSI  manufacturing  poses  no  new  challenges  or 
additional  costs  above  and  beyond  current  VLSI  product  manufacturing.  Reduction  in  weight,  volume 
and  power  through  custom  VLSI  fabrication  and  manufacturing  versus  COT  SFPGAs,  poses  no  additional 
manufacturing  requirements.  Custom  VLSI  implementation  can  further  reduce  weight,  volume  and 
power  consunption  and  possibly  provide  redundancy  (currently  not  a  TS21  ISL  requirement)  by  allowing 
embedded  or  shared  redundancy  as  opposed  to  dedicated  hot  standby  (duplicate  unit)  redundancy. 

Provided  that  a  standard  interface  with  adequate  radar  data  rate  capacity  is  utilized,  the 
physical  ISL  to  onboard  subsystem  interface  poses  no  significant  manufacturing  cost  or  schedule 
requirements  above  those  for  ISL  external  satellite  communication  (transmission  interface). 
Automated  manufacturing  and  test  equipment,  as  well  as  chip  sets,  already  exists  in  numerous 
fabrication  facilities  for  such  standard  interfaces. 

The  choice  of  HDLC  with  QoS  service  extensions  for  the  only  communications  protocol 
above  the  physical  layer  greatly  reduces  the  amount  of  risk  associated  with  manufacturing  of  an  ISL. 
For  FPGA  and  custom  VLSI  hardware  implementations,  designs,  hardware  design  language  programs, 
FPGA  cores,  and  test  equipment  and  software  already  exist  to  implement  the  HDLC  protocol.  Only 
minor  programming  and  test  equipment  modifications  would  be  required  to  manufacture  an  extended 
HDLC  protocol  to  include  any  desired  QoS  services. 

5.5  ISL  Communication  Protocol  Definition 

In  order  for  meaningful  communication  to  take  place,  the  information  or  data  exchange  procedures, 
syntax  and  format  must  be  specified.  Communication  protocols  define  and  specify  the  data  exchange 
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procedures,  syntax  and  format.  Based  on  the  previous  discussion,  including  the  five  top  level 
communications  protocol  requirements,  the  ISL  communications  protocol  stack,  or  set  of 
communication  protocol  functions,  is  defined  as  physical  layer  protocol  with  a  data  link  layer 
protocol. 

ISL  communication  occurs  in  two  forms,  external  and  internal  to  a  satellite.  External 
satellite  ISL  communication  occurs  via  wireless,  RF  CDMA  transmissions  between  an  ISL  subsystem 
on  one  TS21  satellite  and  another  ISL  subsystem  on  another  TS21  satellite.  Another  possibility  of 
this  type  is  transmission  between  an  ISL  subsystem  on  a  TS21  satellite  and  a  ground  station.  Both 
are  examples  of  the  general  case  of  an  ISL  subsystem  communicating  with  an  entity  outside  of  the 
spacecraft  on  which  the  ISL  subsystem  resides.  The  second  form  of  ISL  communication  is  internal 
satellite  communication  where  the  ISL  subsystem  communicates  with  one  or  more  other  subsystems 
on  the  same  satellite.  This  type  of  ISL  internal  satellite  communication  is  usually  via  a  physical 
connection  such  as  a  electrical  or  optical  wires,  cables,  busses  or  LANs.  In  the  case  of  external, 
wireless,  RF,  CDMA  based  communication,  the  physical  layer  communications  protocol  is  specified 
via  the  chosen  CDMA  hardware  components,  a  DS-CDMA  protocol.  In  the  case  of  internal 
communication,  the  physical,  and  possibly  the  data  link  and  network  layer  protocols,  are  defined  by 
the  selected  physical  connection,  such  as  a  Myrinet  LAN,  IEEE  1553  or  VME  bus. 

The  DLP  protocol  is  the  only  additional  protocol  that  needs  to  be  specified  above  and 
beyond  physical  link  components.  In  both  internal  and  external  satellite  ISL  communication,  the 
data  link  layer  protocol,  DLP,  can  be  one  and  the  same  protocol.  Having  the  same  DLP  protocol 
for  both  internal  and  external  ISL  communications  yields  performance,  volume,  weight,  power  and 
cost  benefits. 

Given  the  five  top  level  requirements  on  the  design  and  implementation  of  the  ISLP,  1) 
Performance,  2)  COTS  Interoperability,  3)  QoS  functionality,  4)  Interface  and  5)  Manufacturing,  the 
ISLP  is  defined  as  an  HDLC  compliant  data  link  protocol  with  extensions  for  improved  performance 
and  QoS  services.  A  flexible  and  widely  applicable  protocol  mechanism  is  defined,  which  is  applied  to 
an  existing  standard  data  link  protocol  (e.g.,  HDLC),  to  yield  an  ISLP  that  meets  all  requirements. 
The  resulting  TS21  ISLP  is  an  international  standard  HDLC  compliant  and  interoperable  data  link 
protocol  that  can  be  used  for  both  internal  and  external  satellite  communications. 

The  protocol  mechanism  for  increasing  performance,  adding  data  transport  QoS  functions 
and  maintaining  interoperability  is  applied  to  the  HDLC  protocol  to  define  the  new  ISLP.  The 
utilization  of  the  HDLC  compliant  data  link  specifications,  procedures  [IS013239],  elements  of 
procedures  [IS04335],  frame  formats,  frame  content  [ISO3309]  and  services  definitions  [IS08886], 
meets  the  interoperability  requirement  for  a  data  link  layer  protocol.  HDLC  compliant  data  link 
protocols  are  the  overwhelming  majority  (greater  than  95%)  of  all  data  link  protocols  in  use 
[ISO10171].  All  QoS  services,  hence  all  performance  modifications  and  extensions,  are  defined  and 
selected  using  the  existing  HDLC  standard  I,  U,  S  and  XID  frames  [ISO3309,  4335,  8885,  10171]. 
The  additional  control  bits  are  added  to  the  existing  Information  field  of  the  HDLC  I-frame  and  to 
the  Data  User  Sub-field  of  the  XID-frame.  The  HDLC  based  ISLP,  with  its  QoS  extensions  and 
resulting  performance  improvements,  can  meet  the  performance  requirement  of>  100  Mbps  radar 
data  transmission.  The  new  QoS  functions  implement  an  extended  HDLC  based  ISLP  that  provides 
substantial  performance  improvement  and  needed  QoS  services,  while  providing  interoperability  with 
HDLC.  Both  the  connectionless  and  connection  oriented  services  and  classes  of  HDLC  procedures 
are  defined  as  a  part  of  the  ISLP. 

Three  fundamental  data  transmission  link  components,  which  influence  each  other,  can  be 
identified:  the  application,  the  communication  system,  and  the  communication  link.  To  overcome 
several  performance  bottlenecks,  it  is  necessary  that  these  components  adapt  to  each  other.  This  is 
partially  already  done,  e.g.,  the  communication  system  may  adapt  to  the  link  load  (rate  control  of 
Express  Transfer  Protocol  -  XTP,  slow-start  algorithm  of  TCP,  etc.).  ISLP  QoS  support  enables  the 
link  and  the  communication  system  to  adapt  to  the  application  requirements.  The  ISLP  makes 
possible  needed,  innovative  forms  of  adaptation  that  are  not  provided  in  existing  data  link  or  higher 
layer  protocols: 
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1 .  The  communication  system  can  adapt  to  the  application  -  composing  a  tailored  protocol 
that  includes  only  the  functions  required  by  a  given  application  and  type  of  packet. 

2.  The  application  can  and  should  adapt  to  the  communication  link  -  The  application  should 
adapt  to  variable  networking  environments  and  should  also  adapt  its  data  flow  to  the  available 
bandwidth  and  the  required  quality  of  service. 

The  application  of  the  protocol  enhancement  mechanism  to  extend  the  HDLC  service  set  to  include 
new  QoS  services  and  QoS  parameters,  allows  for  the  adaptation  of  the  application,  the 
communication  system,  and  the  communication  link  into  the  optimum  performance  protocol 
services  combination. 

Although  several  directions  have  been  proposed  to  solve  the  protocol  related  problems  of 
adapting  the  application,  the  communication  system,  and  the  link:  a)  improvement  of  the  existing 
protocol  mechanisms,  b)  design  of  new  protocols,  c)  the  Application  Level  Framing  [CT90] 
technique  and  d)  a  demultiplexed  architecture,  none  of  these  techniques  is  interoperable  with  existing 
satellite  or  terrestrial  link  protocols,  components  and  systems,  violating  one  of  the  five  main 
requirements  and  eliminating  benefits  of  the  ISLP  design.  The  ISLP  can  be  tailored  as  a  custom 
protocol  for  each  application  and  environment,  but  in  an  interoperable  manner,  thus  providing  the 
benefit  of  customization  with  the  cost  and  schedule  benefits  of  interoperability. 

With  the  selection  of  the  HDLC  international  standard  data  link  protocol  as  the  baseline 
specification  and  with  extended  services  for  QoS  and  performance,  all  requirements  are  met  without 
the  large  costs  and  risks  of  violating  interoperability.  Through  the  use  of  the  added  QoS  services, 
implemented  with  existing  HDLC  compliant  procedures  and  frame  format  extensions,  the 
application,  communications  system  and  the  communication  link  can  be  adapted  to  one  another.  A 
set  of  QoS  ISLP  services  optimized  for  the  performance  of  the  current  combination  of  link  and 
application(s)  can  be  achieved.  Performance  is  optimized  through  tailoring  of  the  data  link  protocol 
to  each  unique  user  data  and  link  performance  combination.  Each  satellite  implementation  can 
therefore  be  an  optimum  combination  of  data  link  protocol  services  and  implementations,  while  still 
adhering  to  a  standard  protocol.  Not  only  can  all  the  optimized  ISLP  implementations  interoperate 
with  the  standard  HDLC  data  link  protocols  in  existing  links,  but  all  optimized,  customized  versions 
of  the  ISLP  can  interoperate  with  one  another. 

The  new  data  link  protocol  specification  is  the  goal  of  communications  link  designers  and 
users  -  flexibility  for  performance  and  adaptation  to  each  application,  while  retaining  the  advantages 
of  standardization  and  interoperability.  The  cost  savings  of  a  standard  and  interoperability  are 
retained  while  increased  performance  and  tailored  functionality  are  also  provided.  The  remaining 
protocol  specification  effort  becomes  one  of  QoS  service  definition  within  the  standard  HDLC 
protocol. 

5.5.1  QoS  Services 

A  general  and  flexible  model  of  QoS  service  provision  (the  protocol  enhancement  mechanism)  is 
presented  that  does  not  restrict  itself  to  any  of  the  specific  proposals  for  QoS  service  being  discussed 
in  various  industry  and  standards  bodies.  At  the  ISLP  level,  it  is  technologically  viable  to  incorporate 
mechanisms  which  can  provide  customer-specific  QoS  services  even  at  very  high  speeds.  Since  the 
ability  exists  to  implement  the  additional  QoS  functionality  at  high  user  data  throughput  rates,  there 
is  no  need  to  restrict  service  offerings  to  simple  schemes  encoded  in  the  existing  TCP  protocol  type 
of  service  (ToS)  bits. 

Potential  ISLP  QoS  functions  and  associated  parameters,  that  meet  link  requirements  while 
providing  improved  performance,  include 
1 .  Throughput  or  Bandwidth 

a)  MTU  Size 

Number  of  bits  per  data  packet,  requested  by  the  application  and  set  by  link  optimization. 

If  link  optimization  sets  a  size  different  than  an  application  requests,  segmentation  and 

reassembly  functions  must  occur  in  the  ISLP  at  packet  sizes  requested  by  the  application. 

b)  Number  of  Bits  Per  Second 

Number  of  b/s  exchanged  between  service  users,  e.g.,  transactions  per  second 
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c)  Rate 

Quantity  per  unit  of  time  in  which  consecutive  data  packets  have  to  be  delivered  to  the 
destination  user,  e.g.,  the  rate  of  transmitting  frames  in  the  case  of  video  traffic 

d)  Segmented  Delivery 

Whether  segmented  packet  delivery  is  acceptable,  in  which  case  no  segmentation  or 
reassembly  function  is  needed  in  the  ISLP 

e)  Flow  and  Congestion  Control 

Specifying  how  data  packets  are  routed,  dropped,  delayed  and  rerouted  for  space  links 
with  routers,  switches  and  packet  buffers,  e.g.,  multiple  satellite  or  terrestrial  hop 
transmissions 

f)  Compression 

Whether  or  not  to  use  compression  of  data  or  headers,  and  choice  of  compression 
algorithms  and  compression  ratio;  involves  a  tradeoff  between  error  rates  and  bandwidth 

2.  Time 

a)  Delay  Limits 

Acceptable  elapsed  time  between  sending  a  data  packet  from  a  service  user  until  it  is 
received  by  the  destination  service  user 

b)  Response  Time 

Acceptable  two-way  delay  and  the  processing  time,  typically  needed  for  real-time  control 
applications 

c)  Jitter 

Acceptable  rate  variation  in  delay,  response  and  other  transmission  time  parameters 

d)  Interstream  Synchronization 

Amount  of  synchronization,  if  any,  required  between  different  data  streams,  lip  sync 
between  corresponding  audio  and  video  streams 

e)  Expedited  Data 
Delivery  priorities 

3 .  Reliability 

a)  Data  Corruption  Threshold 

Quantity  of  data  corruption  accepted  by  the  service  user,  e.g.,  percentage  of  corrupted 
data  units  within  a  data  stream 

b)  Data  Loss  Threshold 

Acceptable  percentage  of  data  packet  loss 

c)  Replication  of  Data 

Whether  packet  duplicates  must  be  detected  and  or  removed 

d)  Data  Delivery  Order 

Whether  the  data  packets  must  be  delivered  in  the  order  of  their  transmission 

e)  Group  Delivery 

Multicast  and  broadcast  -  whether  transmitted  data  have  to  be  delivered  to  all  members  of 
the  group,  to  at  least  one  member,  or  to  the  majority  of  the  group  members 
f.  FEC 

What  type  of  error  detection  and  correction  algorithm  or  encoding  to  use  including  the 
selection  of  header  only,  header  and  body,  Cyclic  Redundancy  Code  (CRC)  type  and 
length,  Reed-Solomon  type  and  length,  etc. 

g)  arq 

Whether  to  use  the  standard  Go-back-N  or  the  extended  services  optional  SR-ARQ  with 
multiple  buffers  procedure 

4.  Security 

a)  Access  Security 

Whether  identification  before  setting  up  a  session  is  required 

b)  Data  Security 

What  type  of  data  protection  to  employ,  e.g.,  Data  Encryption  Standard  (DES),  keys, 
length  of  encryption  keys,  etc. 
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c)  Data  Unit  Manipulation 

Management  of  single  data  packets  can  be  specified  in  more  detail,  without  considering 
their  relation  to  other  data  packets  within  a  data  stream 

By  adding  the  ability  to  modify  these  new  QoS  parameters,  the  ISLP  can  be  optimized  for  the 
combination  of  link  characteristics  and  application  (e.g.,  radar  data)  requirements.  The  additional 
QoS  ISLP  services  are  often  viewed  as  transport  protocol  or  higher  layer  protocol  services.  By 
adding  these  services  as  optional  functions  to  the  ISLP,  even  higher  link  performance  can  be 
obtained  through  the  elimination  of  higher  level  protocols.  This  is  the  typical  protocol  stack 
arrangement  used  in  real-time  command  and  control  applications  for  reducing  time  delays  and 
improving  throughput.  The  minimum  protocol  stack  consists  of  a  physical  layer  and  a  data  link 
layer  protocol  with  the  user  application  interfacing  to  the  data  link  layer  protocol. 

5.5.2  QoS  Performance  Functions 

All  QoS  functions,  including  ARQ,  FEC  and  MTU  size  functionality  can  be  considered  performance 
impacting  functions.  The  QoS  functions  and  other  contributors  to  improved  ISLP  performance  are: 

1 .  Compression 

2 .  Multiple  buffer  SR- ARQ 

3.  Adaptive  FEC  -u 

4 .  Adaptive  MTU 

5.  QoS  service  selection  and  implementation  approach 

6.  Upper  layer  protocol  implementation. 

Each  of  these  is  now  discussed  further.  The  quantified  analysis  data  of  the  performance  contribution 
of  each  service  is  specified  in  Section  5.9:  Performance. 

5. 5. 2.1  Compression 

Data  compression  can  be  defined  as  replacing  a  given  bit  pattern  with  an  alternate  bit  pattern  that 
requires  fewer  bits.  As  long  as  one  knows  the  mapping  of  replaced  bit  patterns  to  compressed  bit 
patterns,  known  as  the  compression  algorithm,  the  original  data  bits  can  be  recovered.  Compression 
has  been  a  very  productive  method  for  increasing  data  throughput  using  the  familiar  tradeoff  of 
increased  processing  for  decreased  data  transmission.  A  number  of  compression  standards  exist  for 
voice,  video,  alphanumeric  and  graphical  data.  Experimental  and  non  standard  compression 
algorithms  also  exist.  Whether  or  not  TS21  radar  data  is  compressible  is  not  known  as  of  this  time. 
The  ability  to  implement  compression  and  change  compression  algorithms  allow  for  the  evolution  of 
radar  data  compression.  Compression  ratios,  original  bit  pattern  to  replacement  pattern  bit  counts, 
exist  in  the  ranges  of  100  to  1  to  2  to  1.  For  ISLP  utilizationrboth  protocol  control  information 
and  user  data  can  be  compressed.  Compression  inside  the  ISLP  provides  the  most  benefit  when  the 
user’s  data  has  not  already  been  compressed  before  reaching  the  link  protocol. 

5. 5. 2. 2  ARQ  and  FEC  Coding  Techniques 

Most  data  link  control  (DLC)  protocols  (including  the  ISLP)  fit  into  the  following  structure.  The 
protocol  operates  between  a  transmitter  and  a  receiver.  A  source  feeds  a  sequence  of  messages  into 
the  transmitter.  The  transmitter  adds  some  additional  information  to  the  messages  and  sends  them 
over  a  communication  channel  to  the  receiver.  The  communication  channel  is  unreliable  and  may 
occasionally  lose  or  corrupt  messages,  though  it  cannot  permute  the  order  of  messages  (first-in-first- 
out  -  FIFO  channel).  There  is  also  a  reverse  (similarly  unreliable)  channel  that  permits  the  receiver 
to  send  information  back  to  the  transmitter.  The  purpose  of  the  DLC  protocol  is  to  permit  the 
receiver  to  guarantee  eventual  delivery  of  all  messages  to  the  destination  in  the  same  order  as 
generated  by  the  source. 

Coding  techniques  may  be  used  to  provide  a  more  reliable  communications  system  (reduce  the 
probability  of  error),  or  to  increase  the  efficiency  (throughput)  and  lower  the  cost  of  a  system  (less 
power  required),  or  both.  The  amount  of  improvement  achieved  when  a  coding  scheme  is  used  is 
referred  to  the  coding  gain  for  that  scheme.  The  coding  gain  is  determined  by  plotting  the 
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probability  of  error  versus  Eb/N0  (signal  energy  per  bit/  noise  energy  per  Hertz)  of  both  the  non 
coded  and  coded  transmissions,  then  measuring  the  difference  in  Eb/N0  required  to  achieve  a  given 
error  rate.  Although  the  use  of  coding  schemes  can  produce  impressive  improvements,  it  should  be 
noted  that  at  sufficiently  low  values  of  Eb/N0,  (i.e.,  extreme  channel  interference  or  jamming)  error 
correction  coding  actually  my  make  the  situation  worse.  This  is  common  to  all  coding  schemes. 

Thus  under  conditions  of  severe  jamming,  the  use  of  error  correction  is  not  effective.  The  two  most 
common  methods  utilized  in  communication  systems  for  error  detection  and  correction  are  ARQ  and 

FEC.  .  .... 

ARQ  typically  adds  a  unique  sequence  number  to  the  data  blocks  in  a  transmission  which  is 
incremented  by  one  every  time  the  transmitter  sends  a  new  message.  The  receiver  acknowledges 
every  single  message.  In  practice,  message  sequence  numbers  can  be  reused  (with  care)  and 
acknowledgments  can  be  grouped  together  thereby  not  requiring  a  separate  acknowledgment  per 
message.  The  details  of  these  performance  improvement  techniques  are  similar  to  existing  DLC 
protocols  and  are  not  specified  here.  The  transmitter  has  an  accurate  timer  and  that  there  exists  a 
known  time  interval,  T,  which  is  larger  than  the  round  trip  delay  (of  message  and  acknowledgment) 
across  the  channel.  The  duration  of  message  transmission  is  referred  to  as  a  slot  which  is  used  as  the 
unit  of  time.  ARQ  requires  two  way  communications  for  sending  acknowledgments  of  received 
messages  and  sending  a  request  for  retransmission  for  a  data  block  that  was  never  received,  or 
contained  errors  that  were  not  corrected  by  FEC. 

FEC  adds  redundant  bits  at  the  transmitter  to  the  data  in  the  form  of  an  error  checking  code 
which  can  detect  and  correct  errors  in  data  blocks  or  messages.  FEC  does  not  require  two  way 
communications,  since  the  data  is  encoded  prior  to  transmission  and  the  receiver  system  decodes  the 
data  correcting  the  majority  of  errors  which  may  occur.  FEC  works  in  conjunction  with  ARQ.  If 
errors  are  detected  that  cannot  be  corrected,  ARQ  is  used  to  request  a  retransmission  of  the  data  in 
error. 

5. 5. 2. 3  Multiple  Buffer  Selective  Repeat  ARQ 

Most  DLC  protocols  use  one  of  two  basic  mechanisms  to  recover  from  messages  lost  due  to  errors: 
Go-back-N  or  Selective  Repeat  (SR)  [S87b,  BG87].  The  basic  idea  of  Go-back-N  is  that  packets  from 
A  to  B  are  numbered  sequentially  and  this  sequence  number  is  sent  in  the  header  of  the  frame 
containing  the  packet.  The  Go-back-Number  n,  n  ^  1,  is  the  parameter  that  determines  how  many 
packets  are  transmitted  before  an  acknowledgment  must  be  received.  When  an  error  is  found  in  a 
packet  or  a  packet  is  not  acknowledged,  N  becomes  the  number  of  packets  retransmitted,  even 
though  only  one  of  these  packets  may  have  been  received  in  error.  The  basic  idea  of  SR-ARQ  for 
data  on  a  link  from  A  to  B  is  to  accept  out-of-order  packets  and  to  request  retransmission  from  A 
only  for  those  packets  that  are  not  correctly  received.  The  main  advantage  of  Go-back-N  is  that  the 
implementation  of  the  receiver  is  simple.  There  is  very  little  state  information  to  maintain  and 
buffer  management  is  accomplished  through  a  single  FIFO  buffer.  A  large  numbers  of  variations  on 
the  Go-back-N  protocol  have  appeared  in  the  literature  [M78,  TW79,  T79].  The  use  of  FIFO  buffer 
at  the  receiver  is  of  particular  importance  since  it  disassociates  the  speed  of  the  receiver  processing 
from  the  transmission  rate  of  the  channel.  SR,  while  providing  improved  performance,  is  more 
complex  to  implement,  particularly  in  terms  of  memory  management  at  the  receivers  since  packets 
may  arrive,  and  will  be  accepted,  in  any  order  [S87b,  AP86,  RS89]. 

The  standard  HDLC  protocol  contains  optional  services  for  SR  and  multi-SR  SR-ARQ 
retransmissions.  For  the  ISLP,  the  HDLC  standard  S-frame  format  and  syntax  is  used  to  perform  SR- 
ARQ  in  accordance  with  the  enhanced  multi-SR  option  specified  in  the  HDLC  standard  and 
Amendment  7  to  the  standard  [IS04335a7].  The  ARQ  improvement  in  the  ISLP  protocol  comes 
through  use  of  SR-ARQ,  but  mainly  through  the  manner  in  which  the  SR-ARQ  function  is 
implemented. 

The  Multiple  Buffer  SR-ARQ  concept  is  a  simple  two  or  three  times  replication  of  the  Go- 
back-N  hardware  (e.g.,  having  two  or  three  FIFO  buffers  and  associated  state  information).  The 
advantage  of  Go-back-N  ARQ,  simple  hardware  implementation,  is  therefore  maintained  while 
providing  the  significant  performance  advantages  of  SR-ARQ.  The  Multiple  Buffer  SR-ARQ  uses 
multiple  replicated  versions  of  a  Go-back-N  receiver  in  order  to  provide  improved  performance.  The 
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receiver  has  one  or  more  FIFO  buffers.  Associated  with  buffer  i  is  a  variable,  IN(i)  which  represents 
the  next  message  expected  into  that  buffer.  If  no  specific  message  is  expected  for  that  buffer  (e.g., 
the  buffer  is  empty)  IN(i)  is  set  to  zero.  The  receiver  consists  of  two  portions  that  operate  in  an 
asynchronous  fashion.  The  first  portion  (the  write  section)  receives  messages  from  the  channel  and 
loads  them  into  one  of  the  buffers.  The  second  portion  (the  read  section)  reads  messages  from  one 
of  the  buffer  and  delivers  them  to  the  destination.  A  Go-back-N  implementation  consists  of  a  single 
buffer  and  the  write  section  places  an  incoming  (uncorrupted)  message  into  this  buffer  only  if  the 
sequence  number  matches  the  variable  IN.  The  SR-ARQ  implementation  is  essentially  an  extension 
of  the  Go-back-N  to  multiple  buffers,  where  the  write  section  places  an  incoming  message  into  the 
specific  buffer  whose  IN(i)  matches  the  sequence  number.  More  specifically,  upon  receipt  of  a 
message  n  from  the  channel,  the  write  section  checks  if  any  buffer  has  IN(i)  =  n.  If  so,  it  writes  the 
message  into  the  buffer.  Otherwise,  it  checks  if  some  buffer  has  IN(i)  =  0  and  if  so,  writes  the 
message  into  that  buffer.  In  either  case,  IN(i)  is  updated  and  an  acknowledgment  for  message  n  is 
sent.  If  neither  of  the  above  options  is  possible,  the  message  is  discarded  and  no  acknowledgment  is 
sent.  The  operation  of  the  read  section  is  trivial.  Essentially,  it  keeps  track  of  the  last  message  that 
it  delivered  to  the  destination.  If  a  message  with  a  sequence  number  one  larger  than  this  number 
appears  as  the  first  on  any  buffer,  it  reads  that  buffer  and  delivers  this  message.  The  transmitter 
operation  is  also  quite  simple.  Whenever  a  message  is  transmitted,  a  copy  is  retained  for  possible 
retransmission  until  an  acknowledgment  is  received.  A  message  is  scheduled  for  retransmission  when 
T  seconds  have  elapsed  since  its  previous  transmission.  New  messages  received  from  the  source  are 
assigned  a  sequence  number  and  transmitted  only  when  there  is  no  message  awaiting  retransmission. 
Thus,  upon  completion  of  a  message  transmission,  the  transmit’ er  first  checks  if  any  retransmissions 
are  scheduled.  If  not,  it  transmits  the  first  new  message.  Otherwise,  an  old  message  is  retransmitted 
which  in  general  would  be  the  message  for  which  the  maximum  time  (N  slots)  has  elapsed  since  its 
previous  transmission.  There  are  circumstances  in  which  the  transmitter  can  know  that  the  message 
will  overflow  before  transmitting  it.  As  a  performance  improvement,  it  can  attempt  to  detect  these 
situations  and  not  transmit  a  message  that  is  guaranteed  to  o  verflow  (the  example  below  would  make 
this  clear).  This  decision  is  based  on  the  knowledge  of  the  number  of  buffers  at  the  receiver  and  the 
most  recent  N  Acknowledgment/Negative  Acknowledgment  (ACK/NAK)  messages  it  received.  In 
many  cases  this  is  not  possible  either  because  the  transmitter  is  not  intelligent  enough  (implemented 
in  hardware)  or  because  the  precise  structure  of  the  receiver  (number  of  FIFO  buffers)  is  not  known 
to  the  transmitter.  The  correct  operation  of  the  protocol  does  not  require  the  implementation  of 
this  performance  improvement.  By  replicating  the  simplicity  of  the  Go-back-N  hardware  two  or 
three  times,  the  performance  of  Multiple  Buffer  SR-ARQ  approximates  that  of  the  ideal  SR-ARQ. 

5. 5.2.4  Adaptive  FEC 

Adaptive  FEC  is  the  process  of  varying  the  amouni  of  FEC  redundant  bits,  or  varying  the  method  of 
calculating  the  FEC  bits,  or  both,  depending  upon  tne  link  quality  and  user  data  needs.  A  change  in 
the  coding  rate  from  1/2  to  1/4  is  an  example  of  decreasing  the  amount  of  FEC  bits  in  response  to  a 
higher  quality  (lower  error  rate)  link  or  in  response  to  a  higher  acceptable  error  rate  by  the  user  or 
application.  Changing  the  FEC  algorithm  from  a  Reed-Solomon  to  a  Golay  code  is  an  example  of 
altering  the  method  of  calculating  the  FEC  bits  ir;  response  to  link  error  characteristics  or  user  data 
needs.  ISLs  differ  from  their  terrestrial  counterparts  in  error  characteristics.  Bit  error  rates  (BERs) 
are  typically  lower  on  space  links  with  adequate  signal  to  noise  ratios  (SNR).  Typical  BERs  for  a 
ISLs  are  on  the  order  of  1  O'7,  compared  to  1  O'  for  terrestrial  links.  The  pattern  of  errors  are 
different  in  ISLs.  ISL  errors  typically  are  the  corruption  of  single  bits  here  and  there,  as  opposed  to 
terrestrial  links  where  errors  tend  to  occur  in  bursts  of  several  bits  in  a  row.  The  goal  of  adaptive 
FEC  is  to  use  the  optimum  combination  of  tne  least  number  of  FEC  bits  and  the  least  complex  coding 
algorithm  to  achieve  the  required  error  rate  to  meet  user  data  needs.  ISLs  and  terrestrial  links  require 
different  types  of  FEC  codes  (algorithms)  for  optimum  FEC  of  their  different  error  characteristics. 

In  addition  to  link  characteristics,  application  or  user  error  tolerances  span  a  wide  range  from 
accepting  no  errors  to  accepting  the  loss  of  millions  of  bits.  Different  user  data  require  different  BER 
QoS.  For  example,  a  video  data  transmission  can  tolerate  the  loss  of  entire  packets  with  the  result  of 
a  little  snow  in  the  received  picture.  For  such  video  user  data,  the  number  of  FEC  bits  can  be  reduced, 


39 


AFRL- V S-TR-20L  -1070 


and  perhaps  eliminated  all  together,  because  the  acceptable  BER  is  quite  high.  Any  space  or 
terrestrial  link  has  a  variable  BER,  or  link  quality,  due  to  a  number  of  factors  such  as  transmission 
medium  conditions,  thermal  noise  temperature  of  the  receiver,  Eb/N0  of  the  received  signal,  etc.  The 
use  of  a  FEC  code  tha  is  designed  for  the  worst  case,  to  provide  the  lowest  BER,  results  in  the 
transmission  of  more  1  EC  bits  than  are  required  for  any  given  instant  of  link  quality.  Adapting  the 
number  of  FEC  bits  anc  choosing  a  processing  resource  efficient  code  for  an  acceptable  BER,  will 
result  in  the  transmissioi  of  a  higher  ratio  of  user  data  bits  to  overhead  (i.e.,  FEC)  bits  and  faster 
processing,  yielding  a  hig  her  user  data  throughput  for  the  link. 

The  proposed  ISL 1  contains  the  necessary  user  data  BER  QoS  information  to  allow  for 
decreasing  (or  increasing)  i  he  number  of  FEC  bits  based  on  the  combination  of  link  characteristics 
and  user  data  requirements.  Adapting  the  number  and  complexity  of  FEC  bits  to  the  user  data  needs 
can  decrease  the  FEC  overhead  more  than  link  quality  adaptation  alone.  By  constantly  adjusting  the 
number  of  FEC  bits,  through  die  selection  of  different  codes  or  different  rates  of  the  same  codes, 
based  on  user  data  and  link  qu  lity  parameters,  a  higher  user  data  throughput  is  obtained. 

5. 5.2. 5  Adaptive  MTU 

Adaptive  MTU  is  defined  as  adfc  iting  the  message  transfer  unit  size  to  the  link  quality  and  QoS 
requirements  of  the  transmitted  c  ita.  Adaptive  MTU  can  yield  significant  link  throughput 
performance  improvement.  The  concept  can  be  viewed  as  taking  the  available  transmission  data  rate 
and  dividing  this  rate  into  segment;  called  MTUs,  frames,  packets,  messages,  blocks,  etc.  ARQ,  FEC, 
processing,  segmentation  and  reassc  nbly.  QoS  functions  and  other  link  related  functions  are  then 
performed  on  the  MTU  size  segmen  s.  The  more  segments  (smaller  MTU),  the  more  times  the  link 
related  functions  must  be  executed.  *  onversely,  the  fewer  segments  (larger  MTU),  the  fewer  times 
the  link  related  functions  must  be  exec  uted.  ARQ  and  FEC  functions  are  very  sensitive  to  MTU  size. 
The  fewer  segments  -  the  larger  the  M  -  the  better  the  performance  of  ARQ  and  FEC  functions. 
However,  the  greater  the  bit  error  prob  bility  (or  rate),  pb,  the  greater  probability  of  an  error  in  a 
MTU  or  frame  and  hence  a  greater  numt  ?r  of  retransmissions  are  required  for  larger  MTU  sizes.  In 
addition,  user  data  comes  in  predefined  sc  gment  sizes.  For  example,  voice  data  comes  in  small 
segments  or  packets  with  an  MTU  size  of  near  8  bytes  or  32  bits,  while  video  or  file  transfer  data  can 
come  in  MTU  sizes  of  65  thousand  to  mill  ons  of  bits.  The  best  performance  is  achieved  through 
adapting  the  MTU  size  to  a  size  between  th  ■  optimum  space  or  terrestrial  link  MTU  size  (based  on 
bit  error  rates  and  propagation  delay  times)  and  user  data  MTU  sizes. 

TS21  ISLs  differ  from  terrestrial  link  counterparts.  The  main  characteristic  of  ISLs  relevant 
to  MTU  sizing  is  the  variable  propagation  dek  y  times  in  comparison  to  the  fixed  terrestrial  links.  A 
TS21  constellation  with  inter-satellite  spacing  f  5000  km  has  a  much  different  propagation  delay 
time  than  a  constellation  with  inter-satellite  sp;  ing  of  10  m.  This  means  that  500  times  the 
number  of  data  bits  can  be  sent  and  can  be  in  the  link  pipeline  in  the  5000  km  case  than  in  the  10  m 
case  before  any  acknowledgment  or  indication  of  reception  errors  is  received  at  the  transmitter.  In 
order  to  optimize  link  bandwidth  and  transmission  rate  capability,  the  link  pipeline  should  be  kept 
full  of  data.  This  can  be  accomplished  one  of  two  'ays:  transmit  many  small  messages  or  transmit 
fewer,  larger  messages.  Data  link  protocol  function;  such  as  time-out  timers,  retransmission 
schemes,  error  coding  and  message  acknowledgments  orovide  higher  user  data  throughput  with  fewer, 
larger  messages,  as  opposed  to  using  more,  smaller  me  sages. 

Application  requirements,  in  conjunction  with  :nk  delay  characteristics,  require  that  a  data 
link  protocol  be  flexible  enough  to  accommodate  a  wid  range  of  MTU  sizes.  The  proposed  ISLP 
adaptive  MTU  size  mechanism  is  able  to  adapt  the  prot  col  operation  to  optimize  user  data 
throughput  and  link  bandwidth  utilization  for  both  long  a  d  short  delay  links,  while  maintaining 
interoperability  with  other  links  using  different  MTU  size:  The  ISLP  MTU  sizing  mechanism  can 
allow  different  links  with  different  MTU  sizes  to  interoper  te  without  manual  intervention  required 
at  any  time  before,  during  or  after  MTU  size  adjustments. 

5. 5. 2. 6  QoS  Service  Selection  and  Implementation 

The  combination  of  selected  QoS  functionality  along  with  the  ink  characteristics,  e.g.,  SNR,  error 
rates  and  error  characteristics,  affects  data  throughput  in  that  h  e  more  QoS  functions  that  are  in  use, 
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the  more  processing  is  required.  Some  QoS  functions,  however,  improve  data  throughput 
performance.  The  effects  of  QoS  selection  will  be  determined  by  the  implementation  of  the  QoS 
functions.  A  fast,  parallel  processing  hardware  oriented  implementation  can  reduce  the  effects  of 
performing  additional  QoS  functions  to  the  point  of  not  limiting  performance.  On  the  other  hand,  a 
poor  software  implementation  can  cause  QoS  selection  and  execution  to  become  the  link  bottleneck, 
reducing  data  throughput  to  unacceptable  levels. 

5.5.2. 7  Upper  Layer  Protocol  Implementation 

Upper  layer  protocol  implementation  greatly  affects  the  overall  data  link  throughput  performance. 
This  is  true  even  though  upper  layer  protocol  performance  is  only  loosely  coupled  to  data  link 
protocol  operation.  If  upper  layer  protocols  are  going  to  be  used  over  a  satellite  or  terrestrial  data 
link  and  if  they  are  implemented  in  software,  then  optimization  of  upper  layer  protocols  is  a  must 
for  improved  data  throughput.  The  main  optimization  that  needs  to  be  performed  is  to  reduce  the 
number  of  memory  accesses  required  for  upper  layer  protocol  processing. 

5.6  ISLP  Procedures 

The  ISLP  procedures  are  the  same  as  the  HDLC  procedures,  specified  in  accordance  with  [ISO 1 3239] 
and  [IS04335],  All  ISLP  extensions  and  associated  parameters  can  be  selected  through  the  use  of  the 
existing  HDLC  procedures.  Two  new  XID-frame  responses  to  U-frames  are  required  to  be  defined. 
One  XID-frame  is  sent  in  response  to  the  U-frame  request  for  initiating  ISLP  extended  HDLC 
operation.  A  second  XID-frame  is  sent  in  response  to  the  U-frame  request  for  terminating  ISLP 
extended  HDLC  operation.  If  ISLP  operation  is  always  in  use,  there  is  no  need  for  these  two  new 
responses.  However,  should  a  mix  of  existing  HDLC  based  and  ISLP  operations  be  required,  the  two 
new  XID-frame  responses  are  required. 

The  new  service  extensions  to  HDLC,  turning  the  protocol  into  the  ISLP,  are  therefore 
initiated  in  such  a  way  as  to  be  interoperable  with  existing  HDLC  U-frame  compliant 
implementations  and  with  the  HDLC  standard.  New  QoS  and  QoS  inherent  performance  enhancing 
services  are  added  using  the  existing  procedures  and  frame  structure  of  the  HDLC  standard. 

5.7  ISLP  Frame  Formats 

The  ISLP  frame  formats  are  the  same  as  the  standard  HDLC  frame  formats.  Additional  parameters 
are  specified  for  three  existing  HDLC  frames,  the  I-frame,  U-frame,  S-frame  and  XID-frame. 

5.7.1  ISLP  Information  (I)  Frame 

The  basic  ISLP  frame  format  is  the  same  as  the  HDLC  I-frame  format,  specified  in  accordance  with 
[ISO3309].  Figure  1 1  illustrates  the  basic  HDLC  I-frame  format. 
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Figure  11.  The  Basic  HDLC  I-Frame  Format  is  the  Basis  for  the  ISLP  I-Frame  Format 


The  I-Frame  fields  are  defined  as  follows. 

1 .  Flag  Field 

The  flag  field  contains  the  flag  bit  sequence  used  for  frame  synchronization.  All  frames  must 
start  and  stop  with  a  flag  field  containing  the  same  flag  sequence.  A  single  flag  may  be  used  as 
both  the  closing  flag  for  one  frame  and  the  opening  flag  of  another  frame. 

2 .  Address  Field 

In  command  frames,  the  address  field  identifies  the  data  station(s)  for  which  the  command  is 
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intended.  In  response  frames  the  address  identifies  the  data  station  from  which  the  response 
originated. 

3 .  Control  Field 

The  control  field  indicates  the  type  of  command  or  responses  and  where  appropriate, 
contains  frame  sequence  numbers.  The  control  field  is  used  to  convey  a  command  to  the 
addressed  data  station(s)  to  perform  a  particular  operation  or  to  convey  a  response  to  such  a 
command  from  the  addressed  station. 

4.  Information  Field 

The  information  field  contains  the  user  or  application  data.  Any  sequence  of  bits  of  any 
length  or  structure  may  be  in  the  information  field.  This  field  in  the  I-frame  contains  the 
QoS  selections  and  implementations. 

5 .  Frame  Checking  Sequencing  (FCS)  Field 

This  field  contains  a  CRC  error  detection/correction  FEC  code  for  the  frame  bits  after  the 
opening  flag  and  before  the  FCS  field.  Two  lengths  can  be  selected,  a  16  or  32  bit  CRC,  with 
the  longer  FCS  CRC  code  providing  better  FEC. 

Additional  QoS  implementation  bits  are  placed  in  the  Information  (I)  or  data  field  of  the  HDLC  I- 
frame  to  accommodate  the  additional  QoS  service  control  data.  Figure  12  illustrates  the  general 
frame  structure  of  the  ISLP  with  additional  QoS  bits. 
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Figure  12.  The  General  ISLP  I-Frame  Format  with  added  QoS  bits 


The  QoS  selection  and  implementation  fields  are  defined  as  follows. 

1 .  QoS  Function  Selection  Field 

The  QoS  Function  Selection  field  uses  one  bit  for  each  of  the  21  defined  QoS  functions  with 
1 1  bits  for  future  extensions.  Each  bit  identifies  whether  the  QoS  function  is  included  in  the 
beginning  of  the  Information  field  of  the  I-frame.  Although  the  QoS  Selected  Function 
Identifier  (ID)  field  is  sufficient  for  identifying  the  QoS  functions  on  an  individual  basis,  by 
placing  the  list  of  selected  functions  in  the  front  of  the  user  data,  header  processing  can  be 
performed  before  buffering  of  the  user  data,  greatly  improving  performance.  In  addition,  an 
early  allocation  of  resources  can  be  made  to  further  speed  up  QoS  function  and  user  data 
processing.  Furthermore,  should  the  receiver  reject  any  of  the  selected  QoS  functionality  due 
to  insufficient  resources,  the  XID  frame  to  signal  acceptance/denial  of  QoS  services  can  be 
sent  as  early  in  the  link  negotiation  process  as  possible.  Table  4  depicts  the  QoS  service  to 
QoS  Function  Selection  Bit  mapping. 
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Table  4.  QoS  Function  to  Function  Selection  Bit  Mapping 


QoS  FUNCTION  TO  FUNCTION  SELECTION  BIT  MAPPING  j 

QoS  Function 

QoS  Function  Selection  Bit 
(set  to  a  1  if  the  function  is 
selected) 

Throuqhput  or  Bandwidth 

1 .  Data  packet  (MTU)  size 

1 

2.  Number  of  bits  per  second 

2 

3.  Rate  (for  consecutive  packets) 

3 

4.  Seqmented  delivery 

4 

5.  Flow  control/congestion  control 

5 

6.  Compression 

6 

Time 

7.  Delay  limits 

7 

8,  Response  time 

8 

9.  Jitter 

9  "j 

10.  Interstream  synchronization 

10 

1 1 .  Expedited  data 

1 1 

Reliability 

12.  Data  corruption  threshold 

h—  1 2 

13.  Data  loss  threshold 

|  1 3 

1 4.  Replication  of  data 

14 

15.  Data  delivery  order 

1  5 

16.  Group  delivery 

1  6 

17.  Forward  error  correction  (FEC) 

1  7 

18.  Automatic  repeat  request  (ARQ) 

1  8 

Security 

19. Access  security 

1 9 

20.  Data  security 

20 

2 1 .  Data  unit  manipulation 

21 

22.  Future  Expansion 

22  -  32 

2.  Length  to  User  Data 

The  Length  to  User  field  is  used  to  specify  how  many  bits  of  QoS  information  follow  after 
the  control  field  and  before  the  user  data  in  the  Information  field  of  the  I-frame.  This  allows 
the  parsing  of  header  and  user  data  information  for  immediate,  separate  and  parallel 
processing  and  handling. 

3.  QoS  Selected  Function  ID 

The  QoS  Selected  Function  ID  field  allows  for  the  selection  of  the  specific  implementation  of 
the  QoS  function  chosen  in  the  QoS  Function  Selection  field.  Within  a  QoS  function,  there 
can  be  many  alternative  implementations.  For  example,  with  the  FEC  function  one  can 
chose  options  such  as  block  codes,  convolutional  codes,  Reed-Solomon  1/4  codes,  Reed- 
Solomon  1/2  codes,  any  number  of  custom  encodings,  etc.  Since  many  options  exist  for 
implementing  QoS  functions,  16  bits  are  provided  to  allow  for  current  and  future 
specification  of  up  to  216  or  65,536  implementations  and  implementation  variations. 

4.  QoS  Selected  Function  Length 

The  QoS  Selected  Function  Length  field  provides  the  knowledge  of  how  many  bits  are  used  to 
implement  the  QoS  function.  This  field  also  provides  the  information  of  how  many  bits 
there  are  before  the  user  data  or  the  next  QoS  function  in  order  to  parse  this  field  for 
immediate,  separate  and  parallel  processing  from  any  other  QoS  information  or  user  data.  In 
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the  case  of  FEC  functions,  knowing  immediately  the  number  of  bits  used  for  FEC  can  greatly 
speed  up  processing. 

5.  QoS  Selected  Function  Implementation 

This  field  contains  the  actual  bits  which  are  the  results  of  performing  the  QoS  function.  It 
can  contain  decryption  keys,  FEC  checksums  and  bits,  the  actual  compression  algorithm,  etc. 

Using  the  QoS  bits  within  the  added  QoS  fields  at  the  beginning  of  the  Information  (I)  field,  an 
infinite  number  of  extension  implementations  are  possible.  Figures  illustrating  some  examples  of  the 
main  performance  enhancing  QoS  control  bits  within  the  ISLP  frame  structure  are  given  below. 
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Figure  13.  ISLP  I-Frame  Format  with  added  FEC  QoS  bits 
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For  FEC  implementation,  an  identifier  is  required  to  select  a  FEC  algorithm  for  QoS  performance 
enhancing,  extended  functionality.  The  FEC  function  length  field  is  required  in  order  to  specify  the 
length  of  the  FEC  implementation  field  to  be  able  to  determine  where  the  user  data  begins.  The  FEC 
Function  Implementation  Field  is  used  to  specify  the  bits  used  for  FEC,  and  in  the  case  of  a 
convolutional  algorithm,  the  location  of  FEC  bits,  and  any  other  FEC  parameters. 

Rather  than  placing  the  QoS  service  extensions  in  the  other  types  of  HDLC  frames  (e.g.,  U- 
frame,  S-frame  or  XID-frame),  the  I-frame  is  selected  in  order  to  keep  all  QoS  functionality  with  the 
data  for  which  the  QoS  functions  apply.  This  has  a  number  of  advantages.  The  I-frames  are  self- 
defining.  All  necessary  information  to  decode  the  frames  and  perform  the  extended  QoS  services  are 
together  in  one  place  with  the  data  on  which  the  functions  are  to  be  performed.  There  is  no  storing 
of  QoS  parameters  requiring  a  table  look-up  to  match  functionality  with  data.  Any  receiving 
satellite,  ground  station  or  subsystem  can  decode  the  data  with  minimal  transmissions  and  storage  of 
additional  information.  By  not  utilizing  the  mostly  unconfirmed  S,  U  or  XID  frames,  error  handling 
is  reduced.  No  new  responses  to  S,  U  or  XID  frames  need  be  defined.  By  placing  the  QoS  data  at  the 
beginning  of  the  user  data,  header  processing  can  be  performed  before  buffering  of  the  user  data, 
greatly  improving  performance.  An  early  allocation  of  resources  can  be  made  to  further  speed  up 
QoS  function  and  user  data  processing.  Finally,  should  the  receiver  reject  any  of  the  selected  QoS 
functionality  due  to  insufficient  resources,  the  XID  frame  to  signal  acceptance/denial  of  QoS  services 
can  be  sent  as  early  in  the  link  negotiation  process  as  possible. 

5.7.2  ISLP  Unnumbered  Command  Control  (U)  Frame 

QoS  extension  of  HDLC  to  initiate  the  ISLP  protocol  is  performed  using  the  existing  HDLC  standard 
U-frame  content  and  format  as  specified  within  [IS08885]  and  [IS08885a9].  Figure  15  illustrates 
the  HDLC  U-Frame  structure  and  content. 
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The  U-Frame  fields  are  defined  as  follows. 

1 .  M  bit 

These  are  the  modifier  function  bits,  used  to  select  the  command  to  be  carried  out  by  the 
receiving  station(s).  15  of  the  possible  32  M  bit  combinations  are  defined  in  the  HDLC 
standard  as  existing  station  commands  with  corresponding  responses.  Two  of  the  remaining 
combinations  are  used  to  initiate  and  terminate  the  ISLP  extended  service  operations. 

2.  P/F  bit 

This  is  the  poll  bit,  used  by  the  primary  station  or  combined  station  to  solicit  (poll)  a 
response  or  sequence  of  responses  from  the  secondary  station(s)  or  combined  station 
(1  =  poll/ final). 
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For  selecting  the  ISLP  protocol,  extending  the  HDLC  protocol  for  the  ISLP  defined  QoS  and 
inherent  performance  enhancing  services,  the  five  HDLC  U-Frame  M  bits  are  set  to  a  particular 
combination,  chosen  to  be  01010,  which  does  not  correspond  to  any  of  the  existing  HDLC  standard 
specified  15  command  functions  and  9  response  functions.  The  resulting  U-Frame  initiating  ISLP 
operation  is  depicted  in  Figure  16. 
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Figure  16.  The  HDLC  U-Frame  bit  Pattern  initiating  ISLP  Operation 


With  five  M  bits,  there  are  25  or  32  optional  extensions  that  could  be  specified.  However,  15  of  the 
32  bit  combinations  are  already  used  by  the  existing  HDLC  standard.  Since  for  the  ISLP  there  are 
21  QoS  extensions  defined,  there  are  not  enough  remaining  M  bit  combinations  to  specify  the  QoS 
selections.  In  order  to  maintain  interoperability  with  the  existing  HLDC  Frame  formats  and 
contents,  the  U-frame  cannot  be  used  to  specify  the  exact  QoS  selection.  Instead,  QoS  function 
selection  and  optional  implementations  are  performed  in  the  Information  field  of  the  HDLC 
I-frame.  Allowing  for  future  expansion  of  an  additional  1 1  QoS  functions,  32  bits  are  set  aside  in  the 
I-frame  information  field  to  select  the  desired  QoS  functionality.  The  32  bits  of  the  QoS  Function 
Selection  field  in  Figure  12  provide  for  the  selection  of  the  desired  QoS  functions. 

For  terminating  the  ISLP  protocol  operation,  returning  to  non  extended  HDLC  protocol 
operation,  the  five  HDLC  U-Frame  M  bits  are  set  to  another  particular  combination,  chosen  to  be 
10101,  which  does  not  correspond  to  any  of  the  existing  HDLC  standard  specified  15  command 
functions  and  9  response  functions.  The  resulting  U-Frame  terminating  ISLP  operation  is  depicted  in 
Figure  17. 
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Figure  17.  The  HDLC  U-Frame  bit  Pattern  terminating  ISLP  Operation 


The  HDLC  U-frame  is  used  to  provide  additional  data  link  control  functions  and  unnumbered 
information  transfer.  The  U-frame  is  intended  to  extend  the  number  of  data  link  control  functions. 
The  U-frame  optional  information  field  can  be  used  to  send  information  such  as  status,  application 
data,  operation,  interruption,  temporal  data,  link  layer  programs  or  parameters  to  another  link  node 
over  a  communications  link.  However,  reception  of  the  U-frame  is  not  sequence  number  verified  by 
the  existing  HDLC  link  procedures.  A  U-frame  may  therefore  get  lost  or  duplicated.  In  addition, 
there  is  no  specified  response  to  the  U-frame  information.  Because  U-frames  are  unacknowledged 
and  unnumbered,  they  are  chosen  to  only  convey  the  ISLP  option,  to  convey  that  QoS  extensions 
are  desired.  QoS  specifications  and  function  IDs  are  not  transmitted  via  the  unreliable  U-Frame. 
Should  a  mix  of  existing  HDLC  based  and  ISLP  data  link  protocol  operations  be  required,  two  new 
XID-frame  responses  to  ISLP  U-frames  are  required.  One  XID-frame  is  sent  in  response  to  the 
U-frame  request  for  initiating  ISLP  extended  HDLC  operation.  A  second  XID-frame  is  sent  in 
response  to  the  U-frame  request  for  terminating  ISLP  extended  HDLC  operation.  If  ISLP  operation 
is  always  in  use,  there  is  no  need  for  these  two  new  responses.  Initiation  and  termination  of  ISLP 
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extensions  of  the  HDLC  data  link  protocol  are  therefore  accomplished  via  existing  HDLC  U-frames 
and  procedures,  assuring  interoperability  with  existing  HDLC  U-frame  compliant  implementations 
and  with  the  HDLC  standard. 

5.7.3  ISLP  Supervisory  (S)  Frame 

The  HDLC  S-frame  is  used  to  enter  and  convey  the  SR-ARQ  options  of  the  standard  HDLC  protocol. 
A  multi-SR  option  is  available  allowing  for  the  retransmission  of  non  consecutive  frames 
[IS04335a7].  The  new  ISLP  makes  use  of  the  existing  HDLC  S-frame  to  perform  SR-ARQ.  Figure 
18  illustrates  the  S-Frame  structure  and  content. 
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Figure  18.  The  Basic  HDLC  Supervisory  S-Frame  Format  is  the  Basis  for  ISLP  SR-ARQ 


The  S-Frame  fields  are  defined  as  follows. 

1.  N(R)  bits 

These  are  the  sequence  numbers  of  the  frames  to  be  retransmitted.  For  multi-SR,  any  number 
of  non  sequential  frame  numbers  can  be  placed  in  the  information  field.  The  length  of  the 
N(R)  field  depends  upon  the  maximum  allowable  number  of  outstanding  messages  ranging 
from  8  (3  bits)  to  2,147,483,768  (31  bits). 

2.  P/F  bit 

This  is  the  poll  bit,  used  by  the  primary  station  or  combined  station  to  solicit  (poll)  a 
response  or  sequence  of  responses  from  the  secondary  station(s)  or  combined  station 
(1  =  poll/final). 

For  selecting  the  SR-ARQ  options,  the  first  four  bits  of  the  control  field  are  always  set  to  1011. 

5.7.4  ISLP  Exchange  Information  (XID)  Frame 

The  XID-frame  is  used  in  the  existing  HDLC  standard  to  exchange  data  link  information  between 
two  or  more  stations.  The  information  exchanged  includes  “any  and  all  essential  operating 
characteristics  such  as  identification,  authentication,  and  selection  of  optional  functions  and  facilities 
concerning  each  station.”  “Mechanisms  are  provided  to  permit  the  general  purpose  XID-frame 
information  field  to  be  used  to  negotiate  private  parameters  in  a  single  XID  exchange  simultaneously 
with  negotiation  of  the  defined  basic  parameters”  [IS08885]. 

Confirmation  and  communication  of  QoS  selections  are  performed  using  the  existing  HDLC 
standard  XID-frame  content  and  format  as  specified  within  [IS08885,  IS08885a9].  Figure  19 
illustrates  the  standard  XID  frame  structure  and  content. 
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Figure  19.  The  Basic  HDLC  XID  Frame  Structure  and  Content  is  the  Basis  for  ISLP  QoS  Extension 

Selections 

As  a  part  of  the  ISLP  U-frame  operation,  two  new  XID-frame  responses  to  acknowledge  the  new 
ISLP  U-frames  are  required.  One  XID-frame  is  sent  in  response  to  the  U-frame  request  for  initiating 
ISLP  extended  HDLC  operation.  A  second  XID-frame  is  sent  in  response  to  the  U-frame  request  for 
terminating  ISLP  extended  HDLC  operation.  Again,  if  ISLP  operation  is  always  in  use,  there  is  no 
need  for  these  two  new  responses.  The  new  ISLP  protocol  is  therefore  initiated  in  such  a  way  as  to 
be  interoperable  with  existing  HDLC  U-frame  compliant  implementations  and  with  the  HDLC 
standard.  The  XID-frame  can  also  be  used  to  communicate  the  current  QoS  selections.  The  HDLC 
compliant  XID-frame  used  to  confirm  ISLP  initiation  and  I-frame  QoS  selections  is  illustrated  in 
Figure  20. 
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Figure  20.  The  ISLP  XID  Frame  confirms  QoS  Operation  initiation  with  an  HDLC  compliant  XID 

Frame 
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The  HDLC  compliant  XID-frame  used  to  confirm  U-frame  termination  is  illustrated  in  Figure  21. 
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QoS 

Function 

Selection 


32  bits  all  set  to  0 


Figure  21.  The  ISLP  XID  Frame  confirms  QoS  Operation  termination  with  an  HDLC  compliant 

XID  Frame 

Together  with  the  I-frames  and  U-frames,  the  new  XID-frames  implement  an  extended  ISLP  that  is 
interoperable  with  HDLC,  provides  additional  services  and  additional  performance.  The  existing 
HDLC  standard  service  interfaces  and  frame  formats  can  support  the  new  data  link  services. 


5.8  Interface  Definition 

With  the  use  of  an  extended  HDLC  as  the  ISLP,  interfaces  can  follow  the  ISO  OSI  reference  model 
[IS07498]  standards  for  interfacing  between  the  data  link  protocol  layer  services  [ISO8886]  and: 
physical  protocol  layer  [IS010022],  network  layer  protocols  (e.g.,  IP)  [IS08348],  transport  layer 
protocols  (e.g.,  TCP/UDP)  [ISO8072],  or  the  user  application  itself  [IS09545],  The  existing  ISO 
international  standard  service  interfaces  support  the  new  data  link  services. 

In  addition,  two  de-facto  commercial  standard  interfaces  and  interface  development 
environments  are  also  supported  by  the  new  ISLP.  The  Network  Device  Interface  Specification 
(NDIS)  and  the  Open  Data-Link  Interface  (ODI)  are  compatible  with  ISLP  and  are  used  to  provide 
Internet  protocol  stack  interoperability.  Figure  22  illustrates  the  relationship  between  the  ISLP  and 
the  NDIS  and  ODI  de-facto  interface  standards. 


Application 

Program 

Protocol 

Stack 


NDIS  and  ODI 
Interface 


NDIS  and  ODI 
Driver  Software 
ISLP 

Hardware 

Media 


User  program,  uses  the  lower  layers  for  communication 

Upper  Layer  protocols,  e.g.,  IP,  TCP/UDP, 
each  with  NDIS  and  ODI  interface 


Supplied  for  particular  LAN  or  network  adaptor 

Data  link  Protocol 
LAN  or  network  adaptor 
Cooper,  fiber  or  air 


Figure  22.  The  ISLP  is  compatible  with  NDIS  and  ODI  Interfaces 
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5.9  Performance 

Performance  improvement  is  achieved  through  the  addition  of  performance  enhancing  QoS  services, 
the  optional  elimination  or  encapsulation  of  upper  layer  protocols,  and  a  parallel  processing  and 
VLSI  (e.g.,  FPGA)  hardware  implementation.  Performance  enhancing  QoS  services  and  associated 
functions  are  in  previous  sections  and  include:  variable  compression,  multiple  buffer  SR-ARQ, 
adaptive  FEC  algorithms  and  procedures,  and  dynamic  and  adaptive  MTU  or  data  packet  sizing.  The 
elimination  or  encapsulation  of  additional  upper  layer  protocols  through  the  use  of  the  newly  defined 
additional  data  link  services  provide  another  large  performance  benefit.  The  performance 
improvement  of  the  key  performance  enhancing  QoS  services  of  compression,  multiple  buffer  SR- 
ARQ,  adaptive  FEC  and  adaptive  MTU,  QoS  selection/implementation  and  upper  layer  protocols 
removal/encapsulation/implementation  is  now  quantified  in  the  following  sections. 

5.9.1  Performance  Quantification 

In  order  to  remove  most  variables  and  resulting  validity  restrictions  from  performance 
determinations,  the  link  bit  error  rate  and  link  utilization  percentage  are  used  as  the  performance 
metrics.  This  evaluation  matrix,  link  utilization  versus  link  bit  error  rate,  yields  the  maximum 
useable  results  and  makes  use  of  the  best  existing  data.  Link  utilization,  when  multiplied  times  the 
link  transmission  capacity,  yields  an  independent  determination  of  link  data  throughout  rates  and 
thereby  provides  the  most  often  sought  after  performance  data.  As  a  group,  the  following  sections 
provide  a  detailed  quantification  of  the  ISLP  performance  versus  existing  link  implementation 
options. 

5. 9. 1.1  Compression 

For  satellite  or  terrestrial  data  link  protocol  utilization,  both  protocol  control  information  and  user 
data  can  be  compressed.  Compression  can  achieve  a  range  of  10000%  to  2%  data  throughput 
performance  increase.  Lossless  data  compression  algorithms  on  the  order  of  100  to  1  compression 
have  been  demonstrated  for  video  and  other  types  of  data.  A  100  to  1  compression  would  increase 
data  throughput  by  1 0000%,  or  a  factor  of  1 00.  The  worst  case  benefit  of  a  2%  increase  in 
throughput  would  occur  if  the  data  were  already  compressed  and  only  the  protocol  header  could  be 
compressed  along  with  minimal  compression  of  already  compressed  user  data.  Obviously, 
compression  provides  the  most  benefit  when  the  user’s  data  has  not  already  been  compressed  before 
reaching  the  link  protocol.  Since  the  data  to  be  transmitted  over  the  link  varies  in  the  amount  of 
compression  possible  and  varies  in  whether  or  not  it  has  already  undergone  compression,  an  average 
amount  of  compression  can  be  assumed.  Given  the  ability  to  specify  a  wide  range  of  custom  and 
standard  compression  algorithms  using  the  ISLP  QoS  fields,  a  conservative  average  compression  of 
2  to  1  is  assumed.  Compression  is  therefore  estimated  to  provide  a  50%  improvement  in  link 
throughput. 

5. 9. 1.2  Multiple  Buffer  Selective  Repeat  ARQ 

Multiple  Buffer  SR-ARQ  can  achieve  a  range  of  more  than  100%  to  2.5%  data  throughput 
performance  increase.  The  maximum  throughput  improvement  with  Multiple  Buffer  SR  ARQ  over 
Go-back-N  ARQ  varies  with  a  number  of  factors,  mainly  the  link  error  rate  (or  probability  of  error), 
transmission  rate,  overhead  percentage  (ratio  of  data  bits  to  control,  i.e.,  protocol  and  FEC,  bits), 
and  MTU  (packet)  length.  Using  the  link  performance  formulas  validated  by  operational  use  and 
depicted  in  Equations  1  and  2,  Table  5  summarizes  the  performance  improvement  achievable  with 
SR-ARQ  under  various  link  conditions. 


Equation  1.  Go-Back-N  Normalized  Data  Rate  Formula  [S87a] 
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D  -  ILgj  <1 

c  (i  +  r) 


Equation  2.  SR-ARQ  Normalized  Data  Rate  Formula  [S87a] 

D  =  average  data  rate  in  tyts/sec  delivered  to  the  receiving  station  in  bits/sec 
C  =  link  transmission  rate  in  bits/sec 
D/C  =  normalized  data  rate,  link  efficiency 

r~  length  of  the  packet  or  message  control  (protocol  overhead)  fields/information  in  bits 
/  =  length  of  the  packet  or  message  data  field  or  user  information  in  bits 
p  =  the  packet  or  message  error  probability  =  1  -  (1  -  Pb) 

a  =  parameter  relating  throughput  to  packet,  ratio  of  time  between  frames  to  frame  transmission  time 
—  1  +  tout  /  ti  —  tr/ti  ,  a  >  1 


Table  5a.  SR-ARQ  vs.  Go-Back-N  ARQ  Link  Performance  for  5000  KM  Link  Conditions 


GO-BACK-N  AND  SR-ARQ  LINK  PERFORMANCE 

With  5000  Kilometer  Maximum  TS21  Satellite  Separation 

Link  Parameters 

Go-Back-N 

ARQ 

SR 

ARQ 

SR 

Gain 

Pb 

■^1 

/ 

p 

lout 

ti 

Iproc 

TX 

rate 

a 

D/C 

D/C 

% 

bits 

gg 

bits 

bits 

sec 

sec 

sec 

sec 

b/s 

% 

io"3 

BBS 

307 

3.58E-01 

0.0343 

4.43E-06 

1.67E-02 

0.001 

Ba 

7753 

0.0002 

0.4449 

2775561 

10‘3 

BBS 

4000 

9.84E-01 

0.0344 

4.14E-05 

1 .67E-02 

0.001 

108 

833 

0.0000 

0.0154 

81883 

10-4 

1101 

1.16E-01 

0.0344 

1.24E-05 

1 .67E-02 

0.001 

108 

2779 

0.0024 

0.7865 

32320 

io-4 

4000 

3.39E-01 

0.0344 

4.14E-05 

1 .67E-02 

0.001 

m 

833 

0.0023 

0.6395 

28188 

10"5 

CBS 

3621 

3.69E-02 

0.0344 

3.76E-05 

1 .67E-02 

0.001 

10s 

917 

0,0267 

0.9283 

3377 

1CV5 

EBB 

4000 

4.05E-02 

0.0344 

4.14E-05 

1 .67E-02 

0.001 

Wm 

833 

0.0267 

0.9279 

3371 

10"8 

CBS 

11595 

1.17E-02 

0.0346 

1.17E-04 

1 .67E-02 

0.001 

E*2 

296 

0.2202 

0.9769 

343.66 

10"6 

BEE 

4000 

4.13E-03 

0.0344 

4.14E-05 

1.67E-02 

0.001 

B3 

833 

0.2172 

0.9631 

343.45 

10-7 

M 

36811 

3.69E-03 

0.0351 

3.69E-04 

1.67E-02 

0.001 

108 

96 

0.7353 

0.9926 

35.01 

10'7 

M 

4000 

4.14E-04 

0.0344 

4.14E-05 

1 .67E-02 

0.001 

108 

833 

0.7192 

0.9667 

34.41 

10"8 

m 

116552 

1.17E-03 

0.0367 

1.17E-03 

1.67E-02 

0.001 

108 

32 

0.9624 

0.9977 

3.66 

10"8 

BEE 

4000 

4.14E-05 

0.0344 

4.14E-05 

1 .67E-02 

0.001 

108 

833 

0.9349 

0.9671 

3.44 

10‘9 

368714 

3.69E-04 

0.0417 

3.69E-03 

1 .67E-02 

0.001 

■Em 

12 

0.9951 

0.9993 

0.42 

10*9 

M 

4000 

4.14E-06 

0.0344 

4.14E-05 

1.67E-02 

0.001 

8E3 

833 

0.9638 

0.9671  [ 

0.34 

10"10 

BBS 

1166123 

1.17E-04 

0.0577 

1.17E-02 

1.67E-02 

0.001 

108 

6 

0.9992 

0.9998 

0.058 

10"10 

CEE 

4000 

4.14E-07 

0.0344 

4.14E-05 

1.67E-02 

0.001 

108 

833 

0.9668 

0.9671 

0.034 

io*11 

3687750 

3.69E-05 

0.1081 

3.69E-02 

1 .67E-02 

0.001 

108 

4 

0.9998 

0.9999 

0.011 

10'11 

BEE 

4000 

4.14E-08 

0.0344 

4.14E-05 

1.67E-02 

0.001 

108 

833 

0.9671 

0.9671 

0.0034 

10’12 

M 

11661965 

1.17E-05 

0.2676 

1.17E-01 

1 .67E-02 

0.001 

108 

3 

0.9999 

1.0000 

0.0027 

10"12 

IKES 

4000 

4.14E-09 

0.0344 

4.14E-05 

1.67E-02 

0.001 

108 

833 

0.9671 

0.9671 

0.0003 

1  At  a  link  bit  error  rate  of  10"3,  Go-Back-N  achieves  virtually  no  throughput  while  SR-ARQ  achieves  a  throughput 
near  45%  in  which  case  the  throughput  improvement  of  SR-ARQ  over  Go-Back-N  can  be  viewed  as  the  difference 
between  SR  and  Go-Back-N  divided  by  Go-Back-N  as  opposed  to  simply  the  difference  between  SR  and  Go-Back-N. 
The  improvement  can  also  be  viewed  as  infinite,  an  operational  link  vs.  having  a  non  operational  link. 
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Table  5b.  SR-ARQ  vs.  Go-Back-N  ARQ  Link  Performance  for  10  Meter  Link  Conditions 


GO-BACK-N  AND  SR-ARQ  LINK  PERFORMANCE 

With  10  Meter  Minimum  TS21  Satellite  Separation 

Lipk  Parameters 

Go-Back-N 

ARQ 

SR 

ARQ 

SR 

Gain 

Pb 

V 

/ 

p 

lout 

U 

Ip 

Ip  roc 

TX 

rate 

a 

D/C 

D/C 

% 

bits 

bits 

bits 

sec 

sec 

sec 

sec 

b/s 

% 

10'3 

kb 

307 

3.58E-01 

0.0010 

4.43E-06 

3.33E-08 

0.001 

108 

229 

0.0054 

0.4449 

81 541 

10'3 

KB 

4000 

9.84E-01 

0.0011 

4.14E-05 

3.33E-08 

0.001 

108 

27 

0.0006 

0.0154 

2576 

104 

KB 

1101 

1.16E-01 

0.0010 

1 .24E-05 

3.33E-08 

0.001 

na 

84 

0.0739 

0.7865 

964 

icr* 

KB 

4000 

3.39E-01 

0.0011 

4.14E-05 

3.33E-08 

0.001 

108 

27 

0.0648 

0.6395 

887 

10‘5 

KB 

3621 

3.69E-02 

0.0011 

3.76E-05 

3.33E-08 

0.001 

108 

30 

0.4517 

0.9283 

106 

10-5 

KB 

4000 

4.05E-02 

0.0011 

4.14E-05 

3.33E-08 

0.001 

10® 

27 

0.4503 

0.9279 

10* 

11595 

1.17E-02 

0.0012 

1.17E-04 

3.33E-08 

0.001 

10® 

12 

0.8701 

0.9769 

12.27 

icr6 

KB 

4000 

4.13E-03 

0.0011 

4.14E-05 

3.33E-08 

0.001 

10® 

27 

0.8692 

0.9631 

10.81 

10“7 

KB 

36811 

3.69E-03 

0.0017 

3.69E-04 

3.33E-08 

0.001 

iff® 

6 

0.9757 

0.9926 

1.74 

10'7 

KB 

4000 

4,1 4E-04 

0.001 1 

4.14E-05 

3.33E-08 

0.001 

10® 

27 

0.9564 

0.9667 

1.08 

10'8 

116552 

1.17E-03 

0.0033 

1.17E-03 

3.33E-08 

0.001 

BBm 

M 

0.9944 

0.9977 

0.33 

10* 

HB 

4000 

4.14E-05 

0.0011 

4.14E-05 

3.33E-08 

0.001 

es 

27 

0.9660 

0.9671 

0.11 

10~9 

KB 

368714 

3.69E-04 

0.0084 

3.69E-03 

3.33E-08 

0.001 

108 

3 

0.9984 

0.9993 

0.08 

10‘9 

KB 

4000 

4.14E-06 

0.0011 

4.14E-05 

3.33E-08 

0.001 

10® 

27 

0.9670 

0.9671 

0.01 

io-10 

KB 

1166123 

1.17E-04 

0.0243 

1.17E-02 

3.33E-08 

0.001 

10® 

3 

0.9995 

0.9998 

0.024 

io-10 

4000 

4.14E-07 

0.0011 

4.14E-05 

3.33E-08 

0.001 

10® 

27 

0.9671 

0.9671 

0.001 

io-11 

3687750 

3.69E-05 

0.0748 

3.69E-02 

3.33E-08 

0.001 

108 

3 

0.9999 

0.9999 

0.007 

10'11 

4000 

4.14E-08 

0.0011 

4.14E-05 

3.33E-08 

0.001 

10® 

27 

0.9671 

0.9671 

0.0001 

10-12 

KB. 

11661965 

1.17E-05 

0.2342 

1.17E-01 

3.33E-08 

0.001 

Iml 

3 

1.0000 

1.0000 

0.0023 

10“12 

KB 

4000 

4.14E-09 

0.0011 

4.14E-05 

3.33E-08 

0.001 

10® 

27 

0.9671 

0.9671 

0.0000 

1  At  a  link  bit  error  rate  of  10'3,  Go-Back-N  achieves  virtually  no  throughput  while  SR-ARQ  achieves  a  throughput 
near  45%  in  which  case  the  throughput  improvement  of  SR-ARQ  over  Go-Back-N  can  be  viewed  as  the  difference 
between  SR  and  Go-Back-N  divided  by  Go-Back-N  as  opposed  to  simply  the  difference  between  SR  and  Go-Back-N. 
The  improvement  can  also  be  viewed  as  infinite,  an  operational  link  vs.  having  a  non  operational  link. 
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Table  5c.  SR-ARQ  vs.  Go-Back-N  ARQ  Link  Performance  for  600  KM  Link  Conditions 


GO-BACK-N  AND  SR-ARQ  LINK  PERFORMANCE 

With  600  Kilometer  Satellite-Ground  Down-Link  Operation 

Lipk  Parameters 

Go-Back-N 

ARQ 

SR 

ARQ 

SR 

Gain 

Pb 

/' 

/ 

p 

tout 

ti 

tp 

tproc 

TX 

rate 

a 

D/C 

D/C 

% 

bits 

bits 

bits 

sec 

sec 

sec 

sec 

b/s 

% 

10'3 

ibb 

307 

3.58E-01 

0.0050 

4.43E-06 

2.00E-03 

0.001 

108 

1132 

0.0011 

0.4449 

404821 

10‘3 

IBB 

4000 

9.84E-01 

0.0051 

4.14E-05 

2.00E-03 

0.001 

10s 

124 

0.0001 

0.0154 

12093 

IO-4 

IBS 

1101 

1.16E-01 

0.0050 

1.24E-05 

2.00E-03 

0.001 

108 

407 

0.0163 

0.7865 

4727 

10*4 

IBB 

4000 

3.39E-01 

0.0051 

4.14E-05 

2.00E-03 

0.001 

108 

124 

0.0150 

0.6395 

4163 

10'5 

IBB 

3621 

3.69E-02 

0.0051 

3.76E-05 

2.00E-03 

0.001 

108 

136 

0.1552 

0.9283 

498 

10-5 

IBB 

4000 

4.05E-02 

0.0051 

4.14E-05 

2.00E-03 

0.001 

108 

124 

0.1552 

0.9279 

498 

10  6 

IBB 

11595 

1.17E-02 

0.0052 

1.17E-04 

2.00E-03 

0.001 

108 

46 

0.6425 

0.9769 

52.04 

10-6 

4000 

4.13E-03 

0.0051 

4.14E-05 

2.00E-03 

0.001 

108 

124 

0.6390 

0.9631 

50.72 

10~7 

36811 

3.69E-03 

0.0057 

3.69E-04 

2.00E-03 

0.001 

10® 

17 

0.9389 

0.9926 

5.73 

10-7 

4000 

4.14E-04 

0.0051 

4.14E-05 

2.00E-03 

0.001 

10® 

124 

0.9200 

0.9667 

5.08 

10~8 

IBB 

116552 

1.17E-03 

0.0073 

1.17E-03 

2.00E-03 

0.001 

10® 

7 

0.9904 

0.9977 

0.73 

Iff8 

IBB 

4000 

4.14E-05 

0.0051 

4.14E-05 

2.00E-03 

0.001 

10® 

124 

0.9622 

0.9671 

0.51 

iff* 

IBB 

368714 

3.69E-04 

0.0124 

3.69E-03 

2.00E-03 

0.001 

Bffii 

4 

0.9980 

0.9993 

0.12 

10‘9 

IBB 

4000 

4.14E-06 

0.0051 

4.14E-05 

2.00E-03 

0.001 

108 

124 

0.9666 

0.9671 

0.05 

io-10 

IBB 

1166123 

1.17E-04 

0.0283 

1.17E-02 

2.00E-03 

0.001 

10® 

3 

0.9995 

0.9998 

0.028 

io-10 

4000 

4.14E-07 

0.0051 

4.14E-05 

2.00E-03 

0.001 

10® 

124 

0.9671 

0.9671 

0.005 

10'11 

3687750 

3.69E-05 

0.0788 

3.69E-02 

2.00E-03 

0.001 

10® 

3 

0.9998 

0.9999 

0.008 

10'11 

IBB 

4000 

4.14E-08 

0.0051 

4.14E-05 

2.00E-03 

0.001  1 

10® 

124 

0.9671 

0.9671 

0.0005 

10'12 

IBB 

11661965 

1.17E-05 

0.2382 

1.17E-01 

2.00E-03 

o.ooi ! 

10® 

3 

1.0000 

1.0000 

0.0024 

10‘12 

IBB 

4000 

4.14E-09 

0.0051 

4.14E-05 

2.00E-03 

0.001  1 

108 

124 

0.9671 

0.9671 

0.0001 

1  At  a  link  bit  error  rate  of  10'3,  Go-Back-N  achieves  virtually  no  throughput  while  SR-ARQ  achieves  a  throughput 
near  45%  in  which  case  the  throughput  improvement  of  SR-ARQ  over  Go-Back-N  can  be  viewed  as  the  difference 
between  SR  and  Go-Back-N  divided  by  Go-Back-N  as  opposed  to  simply  the  difference  between  SR  and  Go-Back-N. 
The  improvement  can  also  be  viewed  as  infinite,  an  operational  link  vs.  having  a  non  operational  link. 

D  =  average  data  rate  in  bits/sec  delivered  to  the  receiving  station  in  bits/sec 
C  =  link  transmission  rate  in  bits/sec 
D/C  =  normalized  data  rate,  link  efficiency 

V-  length  of  the  packet  or  message  control  (protocol  overhead)  fields/information  in  bits 
/  =  length  of  the  packet  or  message  data  field  or  user  information  in  bits 
p  -  the  packet  or  message  error  probability  =  1  -  (1  -  pb) 

a  =  parameter  relating  throughput  to  packet,  ratio  of  time  between  frames  to  frame  transmission  time 

=  1  +  tout  /  t,  =  tT/ti  ,  a  >  1 

pb  ~  the  bit  error  probability  of  the  link 

Cut  =  timeout  interval,  at  the  end  of  which  an  acknowledgment  arrives  =  2tp  +  2h  +  tpr0c 
ti  -  time  to  transmit  a  message  -MTU  or  packet  (data  +  overhead  or  control). 
tT  =  ti  +  tout  -  minimum  time  between  successive  packets  or  messages 

tp  =  propagation  delay  time  =  speed  of  light/distance  -  3x1 08  m/s  divided  by  distance  in  meters 
=  0.0167  sec  for  5000  km  and  3.33xl0'8  sec  for  10  m  (TS21  satellite  constellation  ranges) 
tproc  =  packet  or  message  processing  delay 

TX  =  transmission  rate  in  TS21  radar  payload  data  bits  per  second. 
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Figure  23  depicts  the  performance  improvement  available  when  using  SR-ARQ  instead  of  Go-Back-N 
ARQ  with  the  optimum  link  MTU  size  (defined  in  section  5.9. 1.4). 


If  the  ISL  probability  of  error  is  in  the  range  of  10'3  and  107,  then  Multiple  Buffer  SR-ARQ  can 
achieve  a  greater  than  100%  increase  (or  doubling)  in  link  throughput.  Assuming  that  a  typical  link 
spends  50%  of  the  time  at  10'7,  15%  of  the  time  at  10'6  and  10"  ,  7.5%  of  the  time  at  10"5  and  10  *, 
and  spends  5%  of  the  time  operating  at  a  bit  error  rate  of  10"3,  using  a  100%  improvement  for  10" , 
10"4,  and  10"5,  and  a  link  distance  of  600  km,  then  a  31%  improvement  in  data  throughput  is 
expected  through  the  use  of  the  SR-ARQ  QoS. 

5.9. 1.3  Adaptive  FEC 

Adapting  the  FEC  amount  of  bits  and  type  of  encoding  algorithm  to  the  link  quality  increases  the 
link  throughput  about  7%  based  on  COMSAT  experience  in  their  CLA-2000™  satellite  link  product 
[CSAT98].  Adapting  the  number  of  FEC  bits  to  the  user  data  needs  can  decrease  the  FEC  overhead 
to  user  data  ratio  even  more  than  pure  link  quality  adaptation.  If  one  assumes  a  worst  case  of  50% 
FEC  bits,  (e.g.,  a  rate  1/2  code),  then  the  maximum  achievable  gain  is  50%  resulting  from  the 
elimination  of  all  FEC  bits  in  cases  such  as  uncompressed  radar  data  transmission  where  errors  in  the 
transmission  are  allowed.  The  reduction  in  processing  delays  achieved  through  the  reduction  or 
elimination  of  FEC  processing  can  also  add  additional  user  data  throughput  improvement.  If  the  link 
transmission  rate  can  be  increased  in  cases  where  the  processing  delays  from  FEC  are  reduced,  an 
additional  link  throughput  improvement  in  proportion  to  the  processing  reduction  can  be  achieved. 
For  example,  if  FEC  processing  accounts  for  25%  of  the  processing  time  in  the  satellite,  then  the 
complete  elimination  of  FEC  processing  could  achieve  an  additional  throughput  of  25%,  above  the 
maximum  of  50%  achievable  by  not  transmitting  the  FEC  bits.  If  FEC  functionality  is  performed  in 
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parallel  with  other  data  link  or  higher  layer  protocol  functions,  no  processing  gains  and  hence  no 
data  throughput  gains  would  be  realized  through  the  elimination  of  FEC  processing.  Adaptive  FEC  is 
therefore  able  to  increase  link  performance  by  a  maximum  of  50%  and  a  minimum  of  7%.  For 
purposes  of  this  analysis,  the  minimum  of  7%  is  assumed  as  the  expected  performance  gain  resulting 
from  adaptive  FEC  QoS  functionality. 

/ 

5. 9. 1. 4  Adaptive  MTU 

In  general,  the  fewer  segments  -  the  larger  the  MTU  -  the  better  the  performance  of  SR-ARQ  and 
FEC  functions.  Since  user  data  comes  in  predefined  segment  sizes,  the  best  performance  is  achieved 
through  compromise  between  as  large  as  possible  an  ISLP  MTU  size  and  user  data  MTU  sizes.  For 
satellite  transmission,  the  optimum  MTU  size  can  be  approximated  using  the  formula  depicted  in 
Equation  3. 


-L  /-  4  — -i 

°Pt~  2  LV 


Equation  3.  Optimum  MTU  Size  Approximation  Formula  [S87a] 


The  following  table  depicts  the  ranges  of  optimum  MTU  sizes  using  the  formula  in  Equation  3,  the 
minimum  number  of  control  bits,  /  for  the  new  ISLP  and  a  variety  of  link  conditions,  including 
standard  and  new  ISLP  link  protocol  combinations. 


Table  6.  Calculated  Optimum  MTU  Sizes 


|  OPTIMUM  MTU  (PACKET)  LENGTHS  FOR  VARIOUS  LINK  COMBINATIONS 

Link  Characteristics 

Link  Bit  Error  Probability,  pb  | 

/' 

Bill 

EH 

10‘5 

IO'6 

10‘7 

IO'8 

IO'9 

io-10 

io*11 

10'12 

Standard  HDLC  with  HDLC  only 

72 

235 

2648 

8450 

26797 

84817 

2.7E+5 

8.5E+5 

2.7E+6 

8.5E+6 

HDLC  based  ISLP  with  ISLP  only 

136 

307 

DiX 

3621 

11595 

36811 

1.2E+5 

¥ 

Lii 

CO 

1.2E+6 

3.7E+6 

1.2E+7 

Standard  HDLC  with  IPv4,  UDP 

392 

460 

1794 

6069 

19604 

62415 

2.0E+5 

6.3E+5 

2.0E+6 

6.3E+6 

2.0E+7 

Standard  HDLC  with  IPv4,  TCP 

456 

485 

6529 

21128 

67301 

2.1  E+5 

6.8E+5 

2.1E+6 

6.8E+6 

2.1E+7 

HDLC  based  ISLP  with  IPv4,  UDP 

456 

485 

6529 

21128 

67301 

2.1  E+5 

6.8E+5 

2.1  E+6 

6.8E+6 

2.1E+7 

HDLC  based  ISLP  with  IPv4,  TCP 

520 

507 

SI 

6956 

22545 

71852 

2.3E+5 

7.2E+5 

2.3E+6 

7.2E+6 

2.3E+7 

HDLC  based  ISLP  with  ISLP  only  and 

typical  QoS  options  (est.3) 

592 

529 

2155 

7404 

24037 

76647 

2.4E+5 

7.7E+5 

2.4E+6 

7.7E+6 

2.4E+7 

HDLC  based  ISLP  with  IPv4,  UDP  and 
typical  QoS  options  (est.2) 

922 

604 

2611 

9153 

29907 

95561 

3.0E+5 

9.6E+5 

3.0E+6 

9.6E+6 

3.0E+7 

HDLC  based  ISLP  with  IPv4,  TCP  and 
max.  QoS  options  (est.1) 

1760 

712 

3407 

12416 

41082 

1.3E+5 

4.2E+5 

1.3E+6 

4.2E+6 

1.3E+7 

4.2E+7 

1  21  QoS  functions  =  21  x  (16  function  ID  +  32  function  length  bits  +  avg.  of  8  function  implementation  bits)  +  32 
bits  function  selection  bits  +  32  length  to  user  data  bits  +  520  bits 

2  Compression,  response  time,  data  loss  threshold,  data  delivery  order,  FEC,  ARQ,  and  data  security  =  7  x  (16 
function  ID  +  32  function  length  bits  +  avg.  of  8  function  implementation  bits)  +  32  bits  function  selection  bits  + 
32  length  to  user  data  bits  +  456  (HDLC,  IP  and  UDP)  bits 

3  Compression,  response  time,  data  loss  threshold,  data  delivery  order,  FEC,  ARQ,  and  data  security  =  7  x  (16 
function  ID  +  32  function  length  bits  +  avg.  of  8  function  implementation  bits)  +  32  bits  function  selection  bits  + 
32  length  to  user  data  bits  +  136  (HDLC)  bits 

In  order  to  calculate  the  performance  improvement  with  adaptive  MTU,  Table  5c  and  Table  6  (using 
formulas  in  Equations  1,  2  and  3)  are  combined  into  Table  7.  Use  of  Table  5c  data  implies  that  the 
MTU  gains  in  Table  7  are  for  an  ISL  distance  of  600  km.  Combining  Tables  5a  and  5b  with  Table  6 
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would  yield  the  MTU  gains  for  the  extreme  ranges  of  the  ISL,  5000  km  and  10  m.  600  km  is  chosen 
as  the  representative  distance  for  the  TS21  ISL.  A  non  adaptive  MTU  or  message  size  of  4,000  bits 
(500  bytes),  is  typical  of  terrestrial  link  MTU  sizes  and  was  therefore  chosen  as  the  default  non 
adaptive,  fixed  MTU  size. 


Table1'  7.  Adaptive  MTU  Performance  Improvement 


|  ADAPTIVE  MTU  SIZING  PERFORMANCE  GAINS  AT  600  KM  DISTANCE 

Link  Parameters  and  ARQ  Mechanism 

MTU  Optimization 
Gains 

Pb 

bits 

r 

bits 

/ 

optimum 

bits 

Go-Back-N 

D/C 

Selective 

Repeat 

D/C 

/ 

fixed 

bits 

Go-Back-N 

D/C 

Selective 

Repeat 

D/C 

So-Back-N 

D/C 

% 

Selective 

Repeat 

D/C 

% 

103 

136 

307 

0.0011 

0.4449 

4000 

0.0001 

0.0154 

1000 

42.95 

KT' 

136 

1101 

0.0163 

0.7865 

4000 

0.0150 

0.6395 

8.67 

14.70 

KT5 

136 

3621 

0.1552 

0.9283 

4000 

0.1552 

0.9279 

0.00 

0.04 

io-6 

136 

11595 

0.6425 

0.9769 

4000 

0.6390 

0.9631 

0.35 

1.38 

10'7 

136 

36811 

0.9389 

0.9926 

4000 

0.9200 

0.9667 

1.89 

2.59 

10-8 

136 

116552 

0.9904 

0.9977 

4000 

0.9622 

0.9671 

2.82 

3.06 

10'9 

136 

368714 

0.9980 

0.9993 

4000 

0.9666 

0.9671 

3.14 

3.22 

10-1° 

136 

1166123 

0.9995 

0.9998 

4000 

0.9671 

0.9671 

3.24 

3.27 

10'11 

136 

3687750 

0.9998 

0.9999 

4000 

0.9671 

0.9671 

3.27 

3.28 

10"12 

136 

11661965 

1 .0000 

1.0000 

4000 

0.9671 

0.9671 

3.29 

3.29 

Adaptive  MTU  sizing  can  achieve  a  data  throughput  performance  increase  of  43%  to  0.04%  for 
SR-ARQ  for  bit  error  rates  of  10'3  to  10'7.  As  the  bit  error  rate  increases  toward  a  maximum  useable 
rate  of  10  3,  adaptive  MTU  sizing  provides  larger  and  larger  performance  gains.  For  links  operating 
in  high  bit  error  rate  environments,  adaptive  MTU  sizing  provides  a  substantial  data  throughput 
improvement.  Assuming  that  a  typical  link  spends  50%  of  the  time  at  10  1 ,  15%  of  the  time  at  10  6 
and  10'8,  7.5%  of  the  time  at  10 ‘and  10'4,  and  spends  5%  of  the  time  operating  at  a  bit  error  rate  of 
10'3,  then  adaptive  MTU  sizing  yields  a  5.2%  increase  in  data  throughput.  A  typical  throughput 
improvement  of  5.2%  is  therefore  expected  from  the  use  of  adaptive  MTU  sizing  when  used  with  SR- 
ARQ.  Half  of  this  improvement,  or  2.6%  gain,  is  expected  when  adaptive  MTU  sizing  is  used  with 
Go-Back-N  ARQ. 

5. 9. 1.5  QoS  Service  Selection  and  Implementation  Approach 

QoS  selection  affects  data  throughout  in  that  the  more  QoS  functions  that  are  in  use,  the  more 
processing  is  required.  The  hardware  implementation  approach  of  using  FPGAs  in  parallel  is 
expected  to  improve  SR-ARQ  and  all  QoS  function  processing  to  a  point  where  100  Mbps  can  be 
processed  even  when  the  worst  case  QoS  function  combination  is  in  use.  No  reduction  in  data 
throughput  is  expected  from  the  use  of  QoS  functionality,  even  when  the  highest  processing  and 
overhead  bit  transmission  QoS  functions  are  all  selected  at  one  time. 

5. 9. 1.6  Upper  Layer  Protocol  Removal/Encapsulation 

When  the  processing  of  upper  layer  protocols  (e.g.,  IP,  UDP  or  TCP)  is  removed  through  the  use  of 
only  ISLP  QoS  functionality,  an  additional  44%  to  70%  data  throughout  improvement  is  achieved 
from  the  reduced  processing  time  and  protocol  overhead  bit  transmissions.  Table  8  depicts  upper 
layer  protocol  processing  measurements  made  by  MiTech  on  a  typical  computer  system  connected 
to  a  100  Mbps  link.  Similar  results  were  measured  on  a  SUN  Microsystems  UltraSPARC  workstation 
running  the  Solaris  operating  system. 
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Table  8.  Upper  Layer  Protocol  Removal/Encapsulation  Performance  Gains 

UPPER  LAYER  PROTOCOL  PROCESSING  TIMES 


LINUX  2.0.27  Operating  System  on  Pentium  Pro  167  MHz  PC  with  3Com  FastEtherlink  BusMaster  (3c595)  Network 
_  Adapter  on  100  Mbps  FastEthernet  _ _ ^ _  _ 


Approx. 
Bit  Error 
Rate 

(pb) 

Message 

Size 

Message , 
Arrival 
Interrupt 
Time 

IP 

Protocol 

Start 

Time 

Upper 

Layer 

Protocol 

Completioi 

Time 

IP  and  Upper 
Layer 
Protocol 
i  Processing 
Time 

Total 

Processing 

Time 

IP  and  Upper 
Layer  Protocol 
Processing  Time 
(%  of  Total  Time) 

Bits 

Bytes 

(ns) 

(US) 

(ns) 

(ns) 

(ns) 

(%) 

io-7 

1  0 

52100 

53929 

55818 

1889 

3718 

51 

10'7 

100 

835285 

837178 

839169 

1991 

3884 

51 

10‘7 

200 

522122 

524135 

526190 

2055 

4068 

51 

1 0'7 

500 

936124 

938317 

940325 

2008 

4201 

48 

10"7 

1000 

628490 

631059 

633088 

2029 

4598 

44 

io-7 

1500 

647266 

647503 

654236 

3927 

6970 

56 

1 0'7 

2000 

272241 

272478 

279641 

4357 

7400 

59 

IO'7 

4000 

468194 

468443 

478937 

7463 

10743 

70 

10‘7 

10000 

585142 

585380 

607717 

18347 

22575 

81 

io-7 

65000 

265938 

266171 

357004 

95056 

108290 

88 

A  typical  throughput  improvement  of  70%  is  expected  from  the  removal  (via  non  use  or 
encapsulation)  of  upper  layer  protocol  functionality  in  ISL  transmissions. 


5.9.1. 7  Upper  Layer  Protocol  Implementation 

Table  9  depicts  upper  layer  protocol  processing  measurements  made  by  MiTech  on  a  typical 
computer  system  connected  to  a  100  3Mbps  link. 

Table  9.  Upper  Layer  Protocol  Implementation  Performance  Gains 


MPPFR  LAYER  PROTOCOL  IMPLEMENTATION  EFFECT  ON  LINK  PERFORMANCE 


LINUX  2.0.27  Operating  System  on  Pentium  Pro  167  MHz  PC  with  3Com  FastEtherlink  BusMaster  (3c595) 

Network  AdaDter  on  100  Mbps  FastEthernet 


AFRL- V  S-TR-2000- 1 070 


Upper  layer  protocol  implementation  greatly  affects  the  overall  data  link  throughput  performance. 
This  is  true  even  though  upper  layer  protocol  performance  is  only  loosely  coupled  to  data  link 
protocol  operation.  If  upper  layer  protocols  are  going  to  be  used  over  an  ISL  and  if  they  are 
implemented  in  software,  then  optimization  of  upper  layer  protocols  is  a  must  for  improved  data 
throughput. 

Using  mainly  memory  access  reducing  techniques,  MiTech  has  implemented  the  standard 
compliant  IP,  TCP  and  UDP  upper  layer  protocols  in  a  much  more  efficient  manner.  Table  9 
depicts  upper  layer  protocol  processing  measurements  made  by  MiTech  on  a  typical  computer 
system  connected  to  a  100  Mbps  link.  Similar  results  were  measured  on  a  SUN  Microsystems 
UltraSPARC  workstation  running  the  Solaris  operating  system.  As  depicted  in  Table  9,  MiTech’s 
patent  pending  INCA  upper  layer  protocol  implementation  of  the  IP,  UDP  and  TCP  protocol 
combinations  improves  data  throughput  by  as  much  as  41 1%. 

Assuming  that  a  typical  link  spends  50%  of  the  time  at  10'7,  25%  of  the  time  at  10  ,  7.5% 
of  the  time  at  10"5  and  10‘4,  and  spends  10%  of  the  time  operating  at  a  bit  error  rate  of  10‘3,  then  a 
typical  throughput  improvement  of  354%  is  expected  from  the  improved  implementation  (e.g., 
MiTech’s  INCAPatPend)  of  upper  layer  protocols  in  point-to-point  link  transmission.  The 
performance  improvement  from  a  more  efficient  upper  layer  protocol  implementation  is  typically 
greater  than  that  from  all  the  other  data  link  protocol  QoS  performance  optimizations  combined. 

5.9.2  DLP  PERFORMANCE  SUMMARY 

Compression,  SR-ARQ,  adaptive  FEC,  adaptive  MTU  and  either  not  using  an  upper  layer  protocol  or 
optimization  of  upper  layer  protocol  implementation  define  the  pure  performance  modifications  and 
additions  of  the  proposed  ISLP.  Other  QoS  additions  might  provide  performance  improvements 
under  certain  circumstances,  e.g.,  the  elimination  of  the  equivalent  QoS  functions  in  upper  layer 
protocols  or  in  the  end  user  application,  and  the  adaptation  of  FEC  and  other  ISLP  processing  in 
accordance  with  knowledge  about  the  user  data.  Table  10  summarizes  the  performance  gains  findings. 


Table  10.  Expected  and  Possible  Performance  Gains 


PERFORMANCE  IMPROVEMENT  SUMMARY  | 

QoS  Function  or  Mechanism 

Imi 

provement 

Best 

Worst 

Compression 

1000 

2 

50 

Multiple  Buffer  SR-ARQ 

1  00 

2 

31 

Adaptive  FEC 

50 

7 

7 

Adaptive  MTU 

14.7 

0 

5.2 

QoS  Service  Selection  and  Implementation 

-  - 

-  * 

0 

Data  Link  Protocol  Performance  Increase 

1165 

1  1 

9  3 

Upper  Layer  Protocol  Removal/Encapsulation 

70 

51 

70 

Data  Link  Performance  Increase  - 

1  235 

6  2 

163  | 

Upper  Layer  Protocol  Implementation 

41  1 

255 

354 

TOTAL  POSSIBLE  PERFORMANCE  INCREASE 

1  646 

317 

517 

5.9.3  ISLP  vs.  CCSDS,  SCPS  IP/TCP,  and  Internet  IP/TCP 

In  the  previous  section,  the  performance  of  a  link  using  the  ISLP  was  evaluated  relative  to  the 
performance  of  a  link  using  an  HDLC  type  of  data  link  layer  protocol.  The  performance  of  the  new 
ISLP  can  also  be  measured  relative  to  other  existing  satellite  link  implementations  that  employ  more 
than  a  data  link  layer  protocol,  such  as  TCP/IP  protocols  running  over  the  top  of  a  data  link  layer 
protocol.  Three  common  satellite  link  implementations  are  chosen  for  comparison  to  a  new  ISLP 
satellite  link  implementation: 
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1 .  CCSDS  -  Consultative  Committee  for  Space  Data  Systems  protocol  stack 

2.  SCPS  TCP  -  Space  Communications  Protocol  Specification  Transport  Control  Protocol 

3.  Internet  TCP  -  the  standard  Internet  protocol  suite  Transport  Control  Protocol. 

5. 9. 3.1  CCSDS  Space  Link  Protocols 

The  CCSDS  was  formed  in  1982  by  the  major  space  agencies  of  the  world  to  provide  a  forum  for 
discussion  of  common  problems  in  the  development  and  operation  of  space  data  systems.  It  is 
currently  composed  often  member  agencies,  twenty-three  observer  agencies,  and  over  100  industrial 
associates.  Since  its  establishment,  it  has  been  actively  developing  recommendations  for  data  and 
information  systems  standards  to  a)  reduce  the  cost  to  the  various  agencies  of  performing  common 
data  functions  by  eliminating  unjustified  project-  unique  design  and  development,  and  b)  promote 
interoperability  and  cross  support  among  cooperating  space  agencies  to  reduce  operations  costs  by 
sharing  facilities.  CCSDS  products  are  data  and  information  system  Recommendations  (Blue  Books). 
These  Recommendations  serve  as  baseline  documents  for  the  applicable  standards  of  the  participating 
agencies.  It  is  an  iterative  process,  first  among  technical  panel  experts  and  then  among  the  CCSDS 
agencies.  Final  approval  is  by  consensus  of  the  voting  members.  CCSDS  Recommendations  are  also 
being  converted  into  ISO  International  Standards.  CCSDS  Recommendations  are  routinely  submitted 
to  the  ISO  through  ISO  Technical  Committee  20  (TC  20  Aircraft  and  space  vehicles)/  Subcommittee 
13  (SC  13  Space  data  and  information  transfer  systems).  Many  CCSDS  Recommendations  have 
already  been  adopted  as  international  standards,  and  many  others  are  currently  in  the  review  process 
leading  to  adoption  by  ISO.  The  goal  of  CCSDS  is  to  establish  a  world  wide,  open,  CCSDS  compatible 
virtual  space  data  system  for  international  cross  support,  interoperability,  and  science  information 
interchange.  The  CCSDS  protocol  stack  includes  a  physical  layer,  data  link  layer  and  an  application 
layer  (or  user  specified  upper  layer  protocol). 

5. 9. 3. 2  SCPS  Space  Link  Protocols 

In  the  fall  of  1992,  NASA  and  the  Department  of  Defense  jointly  established  a  technical  team  (the 
SCPS  Technical  Working  Group,  or  SCPS-TWG)  to  explore  possibilities  for  developing  common 
space  data  communications  standards.  By  the  end  of  1993,  the  team  concluded  that  wide  segments  of 
the  U.S.  civil  and  military  space  communities  have  common  needs  for  protocols  to  support  in-flight 
monitoring  and  control  of  civil  and  military  spacecraft.  The  most  widely  used  protocols  today  are 
the  Internet  protocols.  These  are  usually  referred  to  as  TCP/IP,  but,  in  fact,  comprise  more  than 
fifty  Internet  standards.  This  communications  baseline  is  robust  and  flexible,  as  a  result  of  hundreds 
of  thousands  of  engineering  hours  and  years  of  use  and  testing.  The  SCPS  provide  modifications  and 
extensions  to  only  a  few  of  these  Internet  protocols,  in  order  to  meet  the  special  requirements  of 
space  communication.  A  primary  goal  of  the  SCPS  effort  was  to  extend  Internet  connectivity  into 
space.  The  rationale  for  this  approach  is  that  both  the  data  systems  and  the  personnel  (designers, 
operators,  users)  associated  with  space  missions  are  already  using  Internet  protocols.  The 
communications  services  that  they  need  in  space  are  very  similar  to  those  they  have  in  ground 
networks.  The  easiest,  lowest  risk,  and  most  direct  way  to  achieve  this  goal  was  to  deemed  to  be  to 
adapt  the  protocols  that  are  used  on  the  ground.  To  provide  reliable  end-to-end  SCPS  Transport 
Protocol  (SCPS-TP)  services,  the  Internet  TCP  and  UDP  were  adapted  to  meet  unique  space  mission 
requirements,  using  IETF  defined  extensions  and  SCPS  defined  modifications.  The  SCPS  protocol 
layers  are  specified  in  a  set  of  four  CCSDS  Recommendations  [CCSDS  1-4].  The  SCPS  protocols 
support  the  transfer  of  space  mission  data  through  space-to-ground  and  space-to-space  data 
subnetworks.  These  protocols  are  not  intended  for  transfer  of  space  mission  data  that  occurs  wholly 
within  ground  systems,  but  rather  are  focused  on  the  unique  requirements  of  data  transfer  through 
subnetworks  that  involve  a  space  data  transmission  path.  The  SCPS  can  be  used  as  an  integrated 
protocol  stack,  or  the  individual  protocols  can  be  used  in  combination  with  CCSDS  or  Internet 
protocols  to  create  custom  profiles  to  support  the  requirements  of  particular  missions.  Previous 
CCSDS  protocols  were  not  designed  to  provide  the  functionality  that  the  SCPS  offer.  CCSDS 
protocols  used  for  return  (or  downlink)  data  provide  error-protected,  sequenced  data  streams.  This 
service  supports  real-time  data  acquisition  and  quick  look  analysis.  It  also  makes  possible  the 
production  of  best-effort  (nearly  complete)  data  sets  from  multiple  dumps  of  data.  But  these 
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protocols  were  not  intended  to  support  automatic,  real-time  retransmission  to  provide  complete  or 
best-effort  data  streams,  or  to  provide  reliable  file  transfer.  Adding  these  services  would  require 
additional  protocol  layers  and  complexity  equal  to  the  SCPS  approach,  but  would  not  yield  the 
benefit  of  Internet  compatibility,  nor  capitalize  on  the  vast  experience  with  Internet  protocol 
development  and  use.  The  SCPS  protocols  include: 

1 .  A  file  handling  protocol  (the  SCPS  File  Protocol,  or  SCPS-FP),  optimized  towards  the  up¬ 
loading  of  spacecraft  commands  and  software,  and  the  downloading  of  collections  of 
telemetry  data 

2.  An  underlying  retransmission  control  protocol  (SCPS-TP),  optimized  to  provide  reliable  end- 
to-end  delivery  of  spacecraft  command  and  telemetry  messages  between  computers  that  are 
communicating  over  a  network  containing  one  or  more  potentially  unreliable  space  data 
transmission  paths 

3.  A  data  protection  mechanism  (the  SCPS  Security  Protocol,  or  SCPS-SP)  that  provides  the 
end-to-end  security  and  integrity  of  such  message  exchange 

4.  A  scaleable  networking  protocol  (the  SCPS  Network  Protocol,  or  SCPS-NP)  that  supports 
both  connectionless  and  connection-oriented  routing  of  these  messages  through  networks 
containing  space  data  links. 

Some  form  of  data  link  protocol  is  required  in  order  to  run  SCPS  TCP  or  other  protocols  over  a  link. 
5. 9. 3. 3  Internet  Link  Protocols 

The  Internet  technology  that  has  resulted  from  research  funded  by  the  Advanced  Research  Projects 
Agency  (ARP A)1  includes  a  set  of  network  standards  that  specify  the  details  of  how  computers 
communicate,  as  well  as  a  set  of  conventions  for  interconnecting  networks  and  routing  traffic. 
Officially  named  the  TCP/IP  Internet  Protocol  Suite  and  commonly  referred  to  as  TCP/IP  (after  the 
names  of  its  two  main  standards),  it  can  be  used  to  communicate  across  any  set  of  interconnected 
networks.  Although  the  TCP/IP  technology  is  noteworthy  by  itself,  it  is  especially  interesting 
because  its  viability  has  been  demonstrated  on  a  large  scale.  It  forms  the  base  technology  for  a  global 
Internet  that  connects  homes,  university  campuses  and  other  schools,  corporations,  and  government 
labs  in  61  countries.  An  outstanding  success,  the  Internet  demonstrates  the  viability  of  the  TCP/IP 
technology  and  shows  how  it  can  accommodate  a  wide  variety  of  underlying  network  technologies. 
The  Internet  protocols  include  more  than  50  protocols  from  the  data  link,  network,  transport, 
session,  presentation  and  application  protocol  layers.  The  protocols  of  interest  are  the  Internet 
network  protocol  -  IP,  and  the  transport  protocol  -  TCP.  Some  form  of  data  link  protocol  is 
required  in  order  to  run  TCP/IP  protocols  over  a  link. 

5,9.4  ISLP  vs.  CCSDS,  SCPS  IP/TCP,  and  Internet  IP/TCP  Performance  Summary 
The  CCSDS  and  ISLP  protocol  can  be  used  by  themselves  for  a  complete  ISL  transmission  capability. 
The  SCPS  and  Internet  protocols  require  lower  network  and  data  link  layer  protocols  in  order  to 
form  a  complete  link  transmission  capability.  Table  1 1  depicts  the  performance  of  various  link 
protocol  combinations  that  form  a  complete  ISL  transmission  capability.  Figures  24  and  25  illustrate 
the  ISLP  satellite  link  performance  versus  SCPS  and  Internet  satellite  link  protocol  combinations. 

As  can  be  seen  from  Table  1 1,  and  Figures  24  and  25,  the  new  ISLP  provides  a  substantial 
performance  improvement  over  existing  satellite  link  implementations  despite  offering  the  QoS 
functions  which  the  other  link  implementations  do  not  offer.  The  ISLP  is  the  only  implementation 
providing  a  useable  link  at  high  error  rates.  SCPS  is  optimized  for  ground  to  satellite  link 
transmissions  and  requires  upper  layer  protocols  and  falls  short  of  ISLP  performance,  particularly,  as 
link  bit  error  rates  increase.  Internet  TCP/IP  is  obviously  not  suited  for  satellite  link  transmission 
due  to  its  design  and  operation  based  on  terrestrial  link  delay  and  error  characteristics.  CCSDS  suffers 
from  a  high  overhead  due  to  its  design  as  a  general  purpose,  multiple  user,  multi-addressable 
spacecraft  experiment/entity  protocol.  The  best  existing  link  offering,  SCPS,  optimized  for  satellite 
link  transmission,  falls  7%  short  of  the  ISLP  (non  compression)  link  utilization.  If  the  ISLP 


'  ARPA  was  called  the  Defense  Advanced  Research  Projects  Agency  for  several  years  during  the  1980s 
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compression  QoS  is  utilized,  ISLP  would  outperform  the  next  best  satellite  link  implementation 
(SCPS)  by  more  than  50%. 


Table  1 1 .  Complete  Satellite  Link  Transmission  Capability  Performance  Comparison 


1  SATELLITE  LINK  UTILIZATION  PERFORMANCE  COMPARISON  | 

Complete  Link  Transmissior 
Capability  Protocol  Stack 

Link  Bit  1 

Error  Rate  I 

1  E  -  0  8 

IE-07 

1  E  -  0  6 

1  E  -  0  5 

IE-04 

IE-03 

SCPS  [CCSDS5,  CCSDS6] 
SCPS  TCP-only 

H 

H 

91 

85 

61 

0 

SCPS  TCP/IP  over  ISLP 

93 

92 

88 

78 

47 

0 

SCPS  TCP/IP  over  HDLC 

92 

89 

69 

22 

2 

0 

SCPS  TCP/IP  over  CCSDS 

55 

54 

51 

43 

22 

0 

Internet  [CCSDS5] 
Internet  TCP-only 

91 

76 

53 

39 

1  3 

0 

Internet  TCP/IP  over  ISLP 

90 

74 

51 

35 

9 

0 

Internet  TCP/IP  over  HDLC 

90 

72 

40 

1  0 

0 

0 

Internet  TCP/IP  over  CCSDS 

53 

44 

30 

20 

5 

0 

CCSDS 1 

59 

58 

57 

52 

38 

0 

HDLC  (Go-Back-N)2 

99 

96 

77 

26 

3 

0 

ISLP  2 

100 

99 

98 

93 

79 

44 

1  CCSDS  data  estimated  from  [CCSDS5,CCSDS6] 

2  From  Table  5 


Figure  24.  ISLP  Link  Performance  Versus  SCPS  Link  Protocol  Combinations 
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Figure  25.  ISLP  Link  Performance  Versus  Internet  Link  Protocol  Combinations 


In  the  cases  where  the  new  ISLP  is  utilized  with  the  TCP/IP  protocols  (SCPS  or  Internet),  where 
TCP/IP  functionality  is  used  to  control  link  transmissions,  ISLP  still  provides  performance 
improvement,  especially  in  high  link  bit  error  rate  situations.  In  cases  where  the  TCP/IP  protocols 
are  encapsulated  within  the  ISLP  data  field  of  the  ISLP  messages,  preserving  TCP/IP  functionality 
between  end-to-end  TCP/IP  users  on  the  ground,  but  not  using  TCP/IP  functionality  for  satellite  link 
control,  ISLP  can  provide  near  the  performance  improvement  of  utilizing  ISLP  by  itself,  more  than 
50%  with  compression. 

Encapsulation  of  TCP/IP  protocols  within  the  ISLP  protocol  data  fields,  would  seem  to  be 
the  best  mode  of  operation  for  performance  and  maintaining  end-to-end  TCP/IP  Internet 
interoperability.  The  utilization  of  the  new  ISLP  in  this  manner  can  provide  an  approximately  70% 
increase  in  data  throughput  while  providing  a  complete  set  of  QoS  functions  and  maintaining  Internet 
interoperability. 

5.10  Discussion 

The  added  functionality  and  performance  of  the  modified  HDLC  protocol  may  not  required, 
particularly  if  no  payload  data  and  low  data  rates  are  transferred  across  the  ISL.  In  this  case,  the 
recommendation  is  to  use  standard  HDLC  as  the  ISL  data  link  layer  protocol  (ISLP).  The  use  of  the 
HDLC  protocol  provides  the  necessary  link  operation,  data  formatting  and  error  handling 
functionality  while  maximizing  the  potential  use  of  COTS  wireless  CDMA  communications 
components  such  as  FPGAs,  firmware  and  existing  hardware.  The  use  of  the  existing,  national  or 
international  standard  protocol  frame  structures  and  bit  definitions  provides  interoperability  with 
existing  satellite  and  terrestrial  communication  links  including  SCPS,  CCSDS  and  the  Internet 
protocol  suites  of  TCP/UDP/IP.  Links  before  and  after  the  satellite  link  using  the  ISLP  (HDLC) 
require  no  modifications  or  new  information  exchange  interfaces. 

An  Application  Program  Interface  (API)  will  provide  the  minimum  functionality  needed  to 
initiate,  terminate,  suspend,  test  and  otherwise  operate  the  ISL.  The  API  provides  the  interface  to 
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the  ISL  functionality  for  the  external  ISL  subsystem  applications  that  require  access  to  ISL 
functionality  or  link  data  transmissions. 

Modification  of  the  HDLC  protocol  for  reduced  overhead  and  improved  performance  is 
possible  while  still  being  able  to  utilize  COTS  components.  A  detailed  description  of  this  process  and 
its  implementation  has  been  provided.  A  flexible  and  widely  applicable  protocol  enhancing 
mechanism  is  described  that  when  applied  to  link  protocols  (data  link  -  e.g.,  HDLC,  network  -  e.g.,  IP 
or  transport  -  e.g.,  TCP,  UDP),  enhances  performance  and  functionality  significantly  over  existing 
satellite  link  protocols.  The  protocol  mechanism  uses  undefined,  optional  bit  patterns  in  protocol 
headers  and  bits  in  the  beginning  of  the  user  data  field  in  existing  standard  link  protocols  to  define 
new  performance  and  QoS  functions.  The  added  protocol  QoS  functions,  including  compression  and 
multiple  buffer  SR-ARQ,  increase  user  data  throughput  and  provide  the  differentiated  data 
transmission  services  requested  by  network  link  providers  and  users.  The  mechanism  was  applied  to 
an  existing  data  link  protocol,  HDLC,  in  order  to  meet  the  SBIR  objective  of  defining  a  higher 
performance  data  link  protocol.  The  new  protocol  functions  and  resulting  higher  performance  are 
implemented  transparent  to  the  user,  the  existing  communication  protocols  and  link  equipment. 

A  recommended  path  for  the  ISL  protocol  evolution  to  higher  and  higher  data  rates  is  to 
begin  with  standard  HDLC  for  the  low  data  rate  flight  experiment.  When  higher  data  rates  are 
required  for  later  satellite  missions  (e.g.,  radar  payload  data  across  the  ISL),  using  compression  on  the 
data  before  ISL  HDLC  encapsulation  and  transmission  of  the  data  provides  an  excellent  performance 
to  cost,  risk  and  complexity  tradeoff.  Once  data  rates  come  into  the  100  Mbps  range  and  ISL 
distances  and  link  parameters  begin  to  increase  and  vary  over  larger  ranges,  the  reexamination  and 
potential  use  of  the  described  modified  HDLC  protocol  as  the  ISLP  is  encouraged. 
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6 .  ISL  EDU  DEFINITION 

An  ISL  EDU  is  a  prototype  ISL  implementation  that  allows  for  the  validation  and  testing  of  the 
proposed  architecture  and  components  in  the  controlled  environment  of  a  testbed. 

6.1  Purpose  , 

The  purpose  of  the  ISL  EDU  definition  is  to  provide  an  ISL  demonstration  system  that  meets  the 
TS21  flight  experiment  requirements  and  program  schedule.  An  ISL  EDU  is  defined  that 
demonstrates  the  feasibility  of  achieving  the  three  main  technology  requirements:  payload  data 
transmission,  ranging  and  timing  calculations. 

6.2  Scope 

The  scope  of  the  ISL  EDU  definition  is  limited  to  what  can  be  achieved  by  an  October  2000  time 
frame  within  the  budget  constraints  of  the  SBIR  and  TS21  funding  vehicles.  The  ISL  EDU  will 
demonstrate  the  ability  to  transmit  data  via  wireless  DS-CDMA  as  well  as  demonstrate  the  ability  to 
perform  ranging  and  timing  synchronization  functions.  Demonstration  of  the  three  main 
technology  requirements:  data  transmission,  ranging  and  timing  calculations,  will  be  provided  on  a 
proof  of  concept  level  and  not  to  the  final  operational  specifications.  The  ISL  demonstration  unit 
will  be  limited  to  providing  the  necessary  functionality  for  assuring  that  the  operational  ISL  system 
requirements  can  be  met  through  extrapolation  of  current  architectures,  components  and 
implementation  approaches. 

6.3  Approach 

Maximum  use  of  COTS  components  is  made  with  the  ISL  unique  requirements  confined  to  a 
minimum  of  FPGA  and  software  components.  Cost  and  schedule  are  traded  off  against  ISL 
capabilities  in  an  effort  to  demonstrate  the  most  ISL  functionality  for  the  short  development  time 
and  amount  of  funds  available. 

6.4  EDU  Description 

Two  possible  demonstration  systems  are  presented  with  varying  costs  and  ISL  functionality 
demonstration  capabilities.  Figures  26  and  27  depict  the  proposed  ISL  EDU  possibilities. 


Rx  Signal  Processing: 


Q 


Timing  Recovery 


Figure  26.  TS21  ISL  Demonstration  System 
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Rx  Signal  Processing: 


Figure  27.  TS21  ISL  Enhanced  Demonstration 

The  ISL  demonstration  system  in  Figure  26  is  possibly  to  be  the  fastest  route  to  achieve  a  system 
that  can  measure  distance  between  TX  and  RX  utilizing  DS-CDMA  modulation  techniques.  COTS 
system  components  for  DS-CDMA  are  not  in  abundance  and  those  that  are  available  do  not  provide 
the  demodulation  signals  that  are  required  for  calculating  time  offset  (and  hence  range).  They  are 
also  unlikely  to  be  suitable  for  the  performance  enhancements  required  beyond  October  2000.  Test 
equipment  provides  the  flexibility  that  may  be  required  for  the  present  and  future  investigations  that 
are  required  for  this  project.  The  digital  backend  receiver  is  essential  to  provide  the  DS-CDMA 
demodulation  functions  required  for  range  determination  and  for  future  development.  Data  is  not 
supported  by  this  system  as  it  was  thought  not  to  be  a  significant  technological  challenge  (more  a 
matter  of  development  time)  compared  to  the  timing  and  ranging  capabilities. 

The  transmission  waveform  is  a  fixed  DS-CDMA  sequence  that  is  pre-loaded  into  the 
Hewlett-Packard  (HP)  Electronic  Signal  Generator’s  (ESG)  arbitrary  waveform  generator.  The  HP 
ESG  is  also  a  vector  signal  generator  and  as  such  is  able  to  up-convert  the  baseband  waveform  to  RF. 
A  Power  Amplifier  (PA)  may  be  required  to  boost  the  transmit  signal  to  achieve  the  required  distance 
for  the  demonstration. 

At  the  receive  end,  the  Rohde  &  Schwarz  (R&S)  frequency  spectrum  processor  (FSP)  is  used 
to  downconvert  the  RF  signal  to  an  IF  of  20.4  MHz.  This  is  sampled  by  an  A/D  converter  (ADC) 
module  and  passed  via  a  high-speed  digital  (low-voltage  differential  signaling  -  LVDS)  interconnect  to 
the  baseband  processor.  The  primary  processing  element  of  the  baseband  processor  is  a  Xilinx  Virtex 
FPGA.  The  Virtex  device  supports  the  algorithms  required  to  extract  the  received  signal’s  time- 
offset  from  the  reference  signal.  This  measurement  is  passed  to  the  host  PC  that  performs  the  range 
calculation  for  display. 

The  time  references  are  off-the-shelf  components  from  HP.  The  two  time  reference  units 
can  be  synchronized  via  a  physical  interconnect  and  their  relative  drift  is  then  defined  by  the 
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specifications.  Each  time  reference  will  provide  the  signals  for  frequency  locking  of  the  local  system 
(a  10  MHz  reference)  and  the  1  Hz  signal  for  repetitive  triggering  of  the  transmission  of  the 
waveform  stored  in  the  HP  ESG.  In  the  receiver,  the  time  offset  between  the  1  Hz  trigger  and  the 
received  synchronization  pattern  in  the  CDMA  waveform  will  provide  the  data  for  the  range 
estimation. 

The  equipment  configuration  of  Figure  26  will  support  a  DS-CDMA  on-air  bandwidth  of 
around  8  MHz.  This  is  expected  to  be  sufficient  to  meet  the  range  and  information  rate  requirements 
of  the  October  2000  demonstration.  It  is  worth  noting  that  ranging  accuracy  will,  in  part,  be  a 
function  of  the  bandwidth  of  the  DS-CDMA  system. 

Figure  27  illustrates  the  demonstration  system  enhanced  with  a  data  transmission  facility. 

The  elements  marked  in  red  (beware  if  this  document  has  been  printed)  highlight  the 
additions/changes  to  the  demonstration  system  from  Figure  26. 

The  fixed  length  DS-CDMA  sequence  that  is  stored  in  the  HP  ESG  can  be  modulated  with 
data  up  to  a  maximum  length  (to  be  determined).  For  example,  a  Matlab  program  would  allow  a  text 
string  to  be  entered  via  a  graphical  user  interface  (GUI)  and  then  would  generate  the  modulated  DS- 
CDMA  data  sequence  for  download  to  the  HP  ESG.  This  is  a  non-real-time  operation.  The  ESG 
would  then  repeatedly  transmit  the  modulated  signal  which  is  then  received  and  demodulated  in  order 
to  extract  the  data  string.  The  string  and  the  range  estimation  would  be  displayed  on  the  PC  screen. 
The  rate  of  the  data  transmission  would  likely  be  in  the  range  200  kbps  to  500  kbps  using  a 
modulation  format  that  has  yet  to  be  determined. 

The  primary  additional  functional  elements  of  the  demonstration  system  in  Figure  27  are: 
string  input  and  DS-CDMA  modulation  via  Matlab,  demodulation  functionality  in  the  baseband 
processor  and  received  data  display  functionality  at  the  receiver. 
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7.  CONCLUSIONS 

It  seems  possible  to  be  able  to  implement  an  ISL  system  which  transmits  100  Mbps,  receives  multiple 
100  Mbps  data  transmissions,  calculates  satellite  relative  (to  another  satellite’s  ISL  transmitter) 
position  to  3  mm  and  determines  inter-satellite  cluster  timing  synchronization  to  20  ps.  Using 
DS-CDMA  technology  and  components,  an  ISL  system  operating  over  ranges  of  a  few  meters  to 
5000  km  should  be  achievable  in  a  20  W,  5  kg,  0.3  m3  package  at  a  cost  of  $300K  in  quantities  of 
>  300.  The  use  of  FPGAs,  high  speed  D/A,  A/D  converters  allows  for  the  implementation  of  a 
wireless  RF  DS-CDMA  communications  system  with  HDLC  data  link  protocol  interoperability.  The 
entire  ISL  system  can  be  almost  completely  implemented  in  the  digital  domain,  providing 
exceptional  performance  and  functionality  in  a  small  and  cost  effective  package. 
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8.  RECOMMENDATIONS 

Inter-satellite  link  operation  for  the  distributed,  space  based  SAR  mission  includes  operations  deemed 
technologically  stressing  and  encompassing  a  wide  range  of  ISL  operational  profiles.  Extremely  high 
data  rates,  spacecraft  subsystem  support,  stressing  volume,  weight,  power  and  time  delay/processing 
restrictions,  etc.,  should  make/the  ISL  Operations  Concept  a  useful  ISL  requirements  source  for  a 
number  of  satellite  missions. 

The  ISL  requirements  document  defines  and  documents  a  set  of  ISL  requirements  for 
evaluating  wireless  communication  technologies  and  defining  recommended  ISL  implementations 
capable  of  conducting  satellite  missions.  Additional  uses  for  the  requirements  document  include 
evaluating  proposed  ISL  implementations,  performing  cost  and  risk  tradeoffs  and  gaining  user 
community  acceptance  of  ISL  implementations.  Maintenance  of  the  ISL  Operations  Concept  and 
Requirements  documents  through  periodic  review  and  modification  of  content  for  updated  ISL 
knowledge  would  extend  the  purposes  and  utility  of  these  documents  to  a  number  of  other  satellite 
cluster,  satellite  LAN  or  virtual  satellite  type  missions.  The  unclassified  nature  and  conceptual 
information  level  should  aid  in  ISL  information  dissemination. 

With  a  high,  preferably  20  to  100  Mbps  data  transmission  capability,  the  ISL  could  provide 
additional  satellite  functions  as  well  as  having  the  support  and  backing  of  the  immense  commercial 
wireless  communications  community.  For  example,  if  each  satellite  in  a  cluster  or  virtual  satellite 
LAN  has  to  downlink  payload  data  at  a  high  rate  (e.g.,  100  Mbps),  there  is  a  high  probability  that  no 
ground  station  can  accommodate  multiple  simultaneous  100  Mbps  links  during  one  pass  over  the 
ground  station.  This  would  mean  that  multiple  ground  station  passes  would  be  required  to  downlink 
one  experiment’s  worth  of  data.  Multiple  ground  passes  require  difficult  ground  station  scheduling 
and  satellite  orbit  coordination  with  the  possibility  of  orbit  maneuvers  required  to  provide  the 
necessary  data  downlinking.  With  a  high  data  rate  ISL,  downlinking  of  the  payload  data  during  the 
flight  experiment  could  be  performed  with  one  pass  over  the  ground  station  rather  than  via  multiple 
passes.  All  payload  data  can  be  transmitted  to  one  satellite  in  order  to  be  downlinked  from  one 
satellite,  greatly  simplifying  ground  station  scheduling  and  cluster  management. 

Without  a  high  data  rate  ISL,  real  time  processing  of  payload  data  in  satellite  clusters  by  the 
satellites  in  space  is  unachievable.  Satellite  LANs  with  low  data  rate  LAN  connections  (i.e.,  ISLs) 
suffer  the  same  drawbacks  as  terrestrial  LANs  with  low  speed  connections.  As  witnessed  to  by  the 
move  from  dial-up  slow  speed  modem  connections  to  cable  modems  and  Digital  Subscriber  Loop 
(DSL)  connections,  high  speed  network  link  connectivity  opens  up  new  possibilities  and  markets. 

Without  a  greater  than  2  Mbps  data  transmission  capability,  an  ISL  has  no  commercial 
application  and  hence  is  of  no  interest  to  third  party,  commercial  product  funding  parties.  Without 
commercial  appeal,  an  ISL  is  likely  to  suffer  from  a  lack  of  industry  support,  with  the  manifestations 
of  a  lack  of  support  including  high  initial  and  recurring  costs.  Commercialization  is  a  prime 
requirement  for  SBIR  funding.  If  SBIR  funding  is  to  continue  to  be  available  for  ISL  development,  it 
is  highly  recommended  that  a  greater  than  2  Mbps  data  transmission  capability  remain  an  ISL 
requirement. 

Because  of  the  feasibility  of  an  ISL  as  defined  in  this  effort,  the  development  of  a  CDMA 
based,  high  speed  ISL  is  highly  recommended  to  meet  the  needs  of  future  space  missions  and  to  reap 
the  benefits  the  support  of  the  commercial  wireless  communications  markets. 
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